Paravirtualizing TCP

Abstract

Virtualization has proven consolidation and isolation benefits, but invariably incurs an overhead. This overhead especially penalizes latency sensitive tasks such as tcp processing, because such processing only occurs when a guest is scheduled. We evaluate a system where tcp is paravirtualized. All guest tcp processing below the socket interface takes place in the hypervisor, which enables rapid response to protocol state changes. We have built Leulo, a prototype hypervisor, and a modified Linux guest kernel that outperforms the Kernel Virtual Machine (KVM) and approaches native performance for certain workloads in an http benchmark.

Omni-Kernel: An Operating System Architecture for Pervasive Monitoring and Scheduling

“…To quantify overhead, we seek more realistic workloads, so we use Apache, MySQL, and Hadoop applications. These execute as unmodified Linux binaries in virtual machines, drawing on prior work [10], [11]. All experiments exhibited deterministic behavior across runs, with consistent performance.…”

“…It comprises around 120,000 lines of C code and offers a wide range of commodity OS functionality. We give an overview of the implementation here; see [10], [11], [22] for additional implementation details.…”

“…A VM may be unable to exploit its I/O budget due to infrequent CPU control [10], [11], [42], [43], benefit from particular scheduling because of its I/O pattern [44], [45], or unduly receive resources because of poor accounting [46]. Functionality-enriching virtual I/O devices may lead to significant amounts of work being performed in the VMM on behalf of VMS.…”

PVTCP: Towards practical and effective congestion control in virtualized datacenters

“…Research [25] proposes to offload the whole socket layer (open, accept, read, write, close) into the hypervisor. However, this would greatly complicate a key feature of virtualization: VM live migration [11], because it would introduce a problem similar to that of residual dependencies in process migration [22].…”

Streaming as a hypervisor service

“…to the physical i/o device is crucial, and algorithmic innovations such as mClock [13] and dvt [21] can further strengthen such differentiation, scheduling vigilance is required on the entire vm to i/o device path. For example, a vm may be unable to exploit its i/o budget due to infrequent cpu control [12,36,25], benefit from particular scheduling because of its i/o pattern [34,18], or unduly receive resources because of poor accounting [14].…”