Professional Documents
Culture Documents
Xen PDF
Xen PDF
Paul Barham∗, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris,
Alex Ho, Rolf Neugebauer†, Ian Pratt, Andrew Warfield
University of Cambridge Computer Laboratory
15 JJ Thomson Avenue, Cambridge, UK, CB3 0FD
{firstname.lastname}@cl.cam.ac.uk
ABSTRACT 1. INTRODUCTION
Numerous systems have been designed which use virtualization to Modern computers are sufficiently powerful to use virtualization
subdivide the ample resources of a modern computer. Some require to present the illusion of many smaller virtual machines (VMs),
specialized hardware, or cannot support commodity operating sys- each running a separate operating system instance. This has led to
tems. Some target 100% binary compatibility at the expense of a resurgence of interest in VM technology. In this paper we present
performance. Others sacrifice security or functionality for speed. Xen, a high performance resource-managed virtual machine mon-
Few offer resource isolation or performance guarantees; most pro- itor (VMM) which enables applications such as server consolida-
vide only best-effort provisioning, risking denial of service. tion [42, 8], co-located hosting facilities [14], distributed web ser-
This paper presents Xen, an x86 virtual machine monitor which vices [43], secure computing platforms [12, 16] and application
allows multiple commodity operating systems to share conventional mobility [26, 37].
hardware in a safe and resource managed fashion, but without sac- Successful partitioning of a machine to support the concurrent
rificing either performance or functionality. This is achieved by execution of multiple operating systems poses several challenges.
providing an idealized virtual machine abstraction to which oper- Firstly, virtual machines must be isolated from one another: it is not
ating systems such as Linux, BSD and Windows XP, can be ported acceptable for the execution of one to adversely affect the perfor-
with minimal effort. mance of another. This is particularly true when virtual machines
Our design is targeted at hosting up to 100 virtual machine in- are owned by mutually untrusting users. Secondly, it is necessary
stances simultaneously on a modern server. The virtualization ap- to support a variety of different operating systems to accommodate
proach taken by Xen is extremely efficient: we allow operating sys- the heterogeneity of popular applications. Thirdly, the performance
tems such as Linux and Windows XP to be hosted simultaneously overhead introduced by virtualization should be small.
for a negligible performance overhead — at most a few percent Xen hosts commodity operating systems, albeit with some source
compared with the unvirtualized case. We considerably outperform modifications. The prototype described and evaluated in this paper
competing commercial and freely available solutions in a range of can support multiple concurrent instances of our XenoLinux guest
microbenchmarks and system-wide tests. operating system; each instance exports an application binary inter-
face identical to a non-virtualized Linux 2.4. Our port of Windows
XP to Xen is not yet complete but is capable of running simple
Categories and Subject Descriptors user-space processes. Work is also progressing in porting NetBSD.
D.4.1 [Operating Systems]: Process Management; D.4.2 [Opera- Xen enables users to dynamically instantiate an operating sys-
ting Systems]: Storage Management; D.4.8 [Operating Systems]: tem to execute whatever they desire. In the XenoServer project [15,
Performance 35] we are deploying Xen on standard server hardware at econom-
ically strategic locations within ISPs or at Internet exchanges. We
General Terms perform admission control when starting new virtual machines and
expect each VM to pay in some fashion for the resources it requires.
Design, Measurement, Performance
We discuss our ideas and approach in this direction elsewhere [21];
this paper focuses on the VMM.
Keywords There are a number of ways to build a system to host multiple
Virtual Machine Monitors, Hypervisors, Paravirtualization applications and servers on a shared machine. Perhaps the simplest
is to deploy one or more hosts running a standard operating sys-
∗
Microsoft Research Cambridge, UK tem such as Linux or Windows, and then to allow users to install
†
Intel Research Cambridge, UK files and start processes — protection between applications being
provided by conventional OS techniques. Experience shows that
system administration can quickly become a time-consuming task
due to complex configuration interactions between supposedly dis-
Permission to make digital or hard copies of all or part of this work for joint applications.
personal or classroom use is granted without fee provided that copies are More importantly, such systems do not adequately support per-
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
formance isolation; the scheduling priority, memory demand, net-
republish, to post on servers or to redistribute to lists, requires prior specific work traffic and disk accesses of one process impact the perfor-
permission and/or a fee. mance of others. This may be acceptable when there is adequate
SOSP’03, October 19–22, 2003, Bolton Landing, New York, USA. provisioning and a closed user group (such as in the case of com-
Copyright 2003 ACM 1-58113-757-5/03/0010 ...$5.00.
putational grids, or the experimental PlanetLab platform [33]), but Notwithstanding the intricacies of the x86, there are other argu-
not when resources are oversubscribed, or users uncooperative. ments against full virtualization. In particular, there are situations
One way to address this problem is to retrofit support for per- in which it is desirable for the hosted operating systems to see real
formance isolation to the operating system. This has been demon- as well as virtual resources: providing both real and virtual time
strated to a greater or lesser degree with resource containers [3], allows a guest OS to better support time-sensitive tasks, and to cor-
Linux/RK [32], QLinux [40] and SILK [4]. One difficulty with rectly handle TCP timeouts and RTT estimates, while exposing real
such approaches is ensuring that all resource usage is accounted to machine addresses allows a guest OS to improve performance by
the correct process — consider, for example, the complex interac- using superpages [30] or page coloring [24].
tions between applications due to buffer cache or page replacement We avoid the drawbacks of full virtualization by presenting a vir-
algorithms. This is effectively the problem of “QoS crosstalk” [41] tual machine abstraction that is similar but not identical to the un-
within the operating system. Performing multiplexing at a low level derlying hardware — an approach which has been dubbed paravir-
can mitigate this problem, as demonstrated by the Exokernel [23] tualization [43]. This promises improved performance, although
and Nemesis [27] operating systems. Unintentional or undesired it does require modifications to the guest operating system. It is
interactions between tasks are minimized. important to note, however, that we do not require changes to the
We use this same basic approach to build Xen, which multiplexes application binary interface (ABI), and hence no modifications are
physical resources at the granularity of an entire operating system required to guest applications.
and is able to provide performance isolation between them. In con- We distill the discussion so far into a set of design principles:
trast to process-level multiplexing this also allows a range of guest
operating systems to gracefully coexist rather than mandating a 1. Support for unmodified application binaries is essential, or
specific application binary interface. There is a price to pay for this users will not transition to Xen. Hence we must virtualize all
flexibility — running a full OS is more heavyweight than running architectural features required by existing standard ABIs.
a process, both in terms of initialization (e.g. booting or resuming
versus fork and exec), and in terms of resource consumption. 2. Supporting full multi-application operating systems is im-
portant, as this allows complex server configurations to be
For our target of up to 100 hosted OS instances, we believe this
virtualized within a single guest OS instance.
price is worth paying; it allows individual users to run unmodified
binaries, or collections of binaries, in a resource controlled fashion 3. Paravirtualization is necessary to obtain high performance
(for instance an Apache server along with a PostgreSQL backend). and strong resource isolation on uncooperative machine ar-
Furthermore it provides an extremely high level of flexibility since chitectures such as x86.
the user can dynamically create the precise execution environment
their software requires. Unfortunate configuration interactions be- 4. Even on cooperative machine architectures, completely hid-
tween various services and applications are avoided (for example, ing the effects of resource virtualization from guest OSes
each Windows instance maintains its own registry). risks both correctness and performance.
The remainder of this paper is structured as follows: in Section 2
we explain our approach towards virtualization and outline how Note that our paravirtualized x86 abstraction is quite different
Xen works. Section 3 describes key aspects of our design and im- from that proposed by the recent Denali project [44]. Denali is de-
plementation. Section 4 uses industry standard benchmarks to eval- signed to support thousands of virtual machines running network
uate the performance of XenoLinux running above Xen in compar- services, the vast majority of which are small-scale and unpopu-
ison with stand-alone Linux, VMware Workstation and User-mode lar. In contrast, Xen is intended to scale to approximately 100 vir-
Linux (UML). Section 5 reviews related work, and finally Section 6 tual machines running industry standard applications and services.
discusses future work and concludes. Given these very different goals, it is instructive to contrast Denali’s
design choices with our own principles.
2. XEN: APPROACH & OVERVIEW Firstly, Denali does not target existing ABIs, and so can elide
certain architectural features from their VM interface. For exam-
In a traditional VMM the virtual hardware exposed is function-
ple, Denali does not fully support x86 segmentation although it is
ally identical to the underlying machine [38]. Although full virtu-
exported (and widely used1 ) in the ABIs of NetBSD, Linux, and
alization has the obvious benefit of allowing unmodified operating
Windows XP.
systems to be hosted, it also has a number of drawbacks. This is
Secondly, the Denali implementation does not address the prob-
particularly true for the prevalent IA-32, or x86, architecture.
lem of supporting application multiplexing, nor multiple address
Support for full virtualization was never part of the x86 archi-
spaces, within a single guest OS. Rather, applications are linked
tectural design. Certain supervisor instructions must be handled by
explicitly against an instance of the Ilwaco guest OS in a manner
the VMM for correct virtualization, but executing these with in-
rather reminiscent of a libOS in the Exokernel [23]. Hence each vir-
sufficient privilege fails silently rather than causing a convenient
tual machine essentially hosts a single-user single-application un-
trap [36]. Efficiently virtualizing the x86 MMU is also difficult.
protected “operating system”. In Xen, by contrast, a single virtual
These problems can be solved, but only at the cost of increased
machine hosts a real operating system which may itself securely
complexity and reduced performance. VMware’s ESX Server [10]
multiplex thousands of unmodified user-level processes. Although
dynamically rewrites portions of the hosted machine code to insert
a prototype virtual MMU has been developed which may help De-
traps wherever VMM intervention might be required. This transla-
nali in this area [44], we are unaware of any published technical
tion is applied to the entire guest OS kernel (with associated trans-
details or evaluation.
lation, execution, and caching costs) since all non-trapping privi-
Thirdly, in the Denali architecture the VMM performs all paging
leged instructions must be caught and handled. ESX Server imple-
to and from disk. This is perhaps related to the lack of memory-
ments shadow versions of system structures such as page tables and
management support at the virtualization layer. Paging within the
maintains consistency with the virtual tables by trapping every up-
date attempt — this approach has a high cost for update-intensive 1
For example, segments are frequently used by thread libraries to address
operations such as creating a new application process. thread-local data.
Memory Management
Segmentation Cannot install fully-privileged segment descriptors and cannot overlap with the top end of the linear
address space.
Paging Guest OS has direct read access to hardware page tables, but updates are batched and validated by
the hypervisor. A domain may be allocated discontiguous machine pages.
CPU
Protection Guest OS must run at a lower privilege level than Xen.
Exceptions Guest OS must register a descriptor table for exception handlers with Xen. Aside from page faults,
the handlers remain the same.
System Calls Guest OS may install a ‘fast’ handler for system calls, allowing direct calls from an application into
its guest OS and avoiding indirecting through Xen on every call.
Interrupts Hardware interrupts are replaced with a lightweight event system.
Time Each guest OS has a timer interface and is aware of both ‘real’ and ‘virtual’ time.
Device I/O
Network, Disk, etc. Virtual devices are elegant and simple to access. Data is transferred using asynchronous I/O rings.
An event mechanism replaces hardware interrupts for notifications.
VMM is contrary to our goal of performance isolation: malicious guest OS. The task is easier if the architecture provides a software-
virtual machines can encourage thrashing behaviour, unfairly de- managed TLB as these can be efficiently virtualized in a simple
priving others of CPU time and disk bandwidth. In Xen we expect manner [13]. A tagged TLB is another useful feature supported
each guest OS to perform its own paging using its own guaran- by most server-class RISC architectures, including Alpha, MIPS
teed memory reservation and disk allocation (an idea previously and SPARC. Associating an address-space identifier tag with each
exploited by self-paging [20]). TLB entry allows the hypervisor and each guest OS to efficiently
Finally, Denali virtualizes the ‘namespaces’ of all machine re- coexist in separate address spaces because there is no need to flush
sources, taking the view that no VM can access the resource alloca- the entire TLB when transferring execution.
tions of another VM if it cannot name them (for example, VMs have Unfortunately, x86 does not have a software-managed TLB; in-
no knowledge of hardware addresses, only the virtual addresses stead TLB misses are serviced automatically by the processor by
created for them by Denali). In contrast, we believe that secure ac- walking the page table structure in hardware. Thus to achieve the
cess control within the hypervisor is sufficient to ensure protection; best possible performance, all valid page translations for the current
furthermore, as discussed previously, there are strong correctness address space should be present in the hardware-accessible page
and performance arguments for making physical resources directly table. Moreover, because the TLB is not tagged, address space
visible to guest OSes. switches typically require a complete TLB flush. Given these limi-
In the following section we describe the virtual machine abstrac- tations, we made two decisions: (i) guest OSes are responsible for
tion exported by Xen and discuss how a guest OS must be modified allocating and managing the hardware page tables, with minimal
to conform to this. Note that in this paper we reserve the term guest involvement from Xen to ensure safety and isolation; and (ii) Xen
operating system to refer to one of the OSes that Xen can host and exists in a 64MB section at the top of every address space, thus
we use the term domain to refer to a running virtual machine within avoiding a TLB flush when entering and leaving the hypervisor.
which a guest OS executes; the distinction is analogous to that be- Each time a guest OS requires a new page table, perhaps be-
tween a program and a process in a conventional system. We call cause a new process is being created, it allocates and initializes a
Xen itself the hypervisor since it operates at a higher privilege level page from its own memory reservation and registers it with Xen.
than the supervisor code of the guest operating systems that it hosts. At this point the OS must relinquish direct write privileges to the
page-table memory: all subsequent updates must be validated by
2.1 The Virtual Machine Interface Xen. This restricts updates in a number of ways, including only
Table 1 presents an overview of the paravirtualized x86 interface, allowing an OS to map pages that it owns, and disallowing writable
factored into three broad aspects of the system: memory manage- mappings of page tables. Guest OSes may batch update requests to
ment, the CPU, and device I/O. In the following we address each amortize the overhead of entering the hypervisor. The top 64MB
machine subsystem in turn, and discuss how each is presented in region of each address space, which is reserved for Xen, is not ac-
our paravirtualized architecture. Note that although certain parts cessible or remappable by guest OSes. This address region is not
of our implementation, such as memory management, are specific used by any of the common x86 ABIs however, so this restriction
to the x86, many aspects (such as our virtual CPU and I/O devices) does not break application compatibility.
can be readily applied to other machine architectures. Furthermore, Segmentation is virtualized in a similar way, by validating up-
x86 represents a worst case in the areas where it differs significantly dates to hardware segment descriptor tables. The only restrictions
from RISC-style processors — for example, efficiently virtualizing on x86 segment descriptors are: (i) they must have lower privi-
hardware page tables is more difficult than virtualizing a software- lege than Xen, and (ii) they may not allow any access to the Xen-
managed TLB. reserved portion of the address space.
1714
567
567
263
172
418
518
514
554
550
271
1633
400
1.0
158
0.9
334
310
0.8
Relative score to Linux
0.7
0.6
535
80
0.5
65
0.4
172
150
111
0.3
306
0.2
199
0.1
0.0
L X V U L X V U L X V U L X V U L X V U L X V U
SPEC INT2000 (score) Linux build time (s) OSDB-IR (tup/s) OSDB-OLTP (tup/s) dbench (score) SPEC WEB99 (score)
Figure 3: Relative performance of native Linux (L), XenoLinux (X), VMware workstation 3.2 (V) and User-Mode Linux (U).
mere 3% overhead, the other VMMs experience a more significant ber of simultaneous clients is slowly increased, allowing servers to
slowdown. preload their buffer caches.
Two experiments were performed using the PostgreSQL 7.1.3 For our experimental setup we used the Apache HTTP server
database, exercised by the Open Source Database Benchmark suite version 1.3.27, installing the modspecweb99 plug-in to perform
(OSDB) in its default configuration. We present results for the most but not all of the dynamic content generation — SPEC rules
multi-user Information Retrieval (IR) and On-Line Transaction Pro- require 0.5% of requests to use full CGI, forking a separate pro-
cessing (OLTP) workloads, both measured in tuples per second. A cess. Better absolute performance numbers can be achieved with
small modification to the suite’s test harness was required to pro- the assistance of “TUX”, the Linux in-kernel static content web
duce correct results, due to a UML bug which loses virtual-timer server, but we chose not to use this as we felt it was less likely to be
interrupts under high load. The benchmark drives the database representative of our real-world target applications. Furthermore,
via PostgreSQL’s native API (callable SQL) over a Unix domain although Xen’s performance improves when using TUX, VMware
socket. PostgreSQL places considerable load on the operating sys- suffers badly due to the increased proportion of time spent emulat-
tem, and this is reflected in the substantial virtualization overheads ing ring 0 while executing the guest OS kernel.
experienced by VMware and UML. In particular, the OLTP bench- SPEC WEB99 exercises the whole system. During the measure-
mark requires many synchronous disk operations, resulting in many ment period there is up to 180Mb/s of TCP network traffic and
protection domain transitions. considerable disk read-write activity on a 2GB dataset. The bench-
The dbench program is a file system benchmark derived from mark is CPU-bound, and a significant proportion of the time is
the industry-standard ‘NetBench’. It emulates the load placed on a spent within the guest OS kernel, performing network stack pro-
file server by Windows 95 clients. Here, we examine the through- cessing, file system operations, and scheduling between the many
put experienced by a single client performing around 90,000 file httpd processes that Apache needs to handle the offered load.
system operations. XenoLinux fares well, achieving within 1% of native Linux perfor-
SPEC WEB99 is a complex application-level benchmark for eval- mance. VMware and UML both struggle, supporting less than a
uating web servers and the systems that host them. The workload is third of the number of clients of the native Linux system.
a complex mix of page requests: 30% require dynamic content gen-
eration, 16% are HTTP POST operations and 0.5% execute a CGI
script. As the server runs it generates access and POST logs, so
4.2 Operating System Benchmarks
the disk workload is not solely read-only. Measurements therefore To more precisely measure the areas of overhead within Xen and
reflect general OS performance, including file system and network, the other VMMs, we performed a number of smaller experiments
in addition to the web server itself. targeting particular subsystems. We examined the overhead of vir-
A number of client machines are used to generate load for the tualization as measured by McVoy’s lmbench program [29]. We
server under test, with each machine simulating a collection of used version 3.0-a3 as this addresses many of the issues regard-
users concurrently accessing the web site. The benchmark is run ing the fidelity of the tool raised by Seltzer’s hbench [6]. The OS
repeatedly with different numbers of simulated users to determine performance subset of the lmbench suite consist of 37 microbench-
the maximum number that can be supported. SPEC WEB99 defines marks. In the native Linux case, we present figures for both unipro-
a minimum Quality of Service that simulated users must receive in cessor (L-UP) and SMP (L-SMP) kernels as we were somewhat
order to be ‘conformant’ and hence count toward the score: users surprised by the performance overhead incurred by the extra lock-
must receive an aggregate bandwidth in excess of 320Kb/s over a ing in the SMP system in many cases.
series of requests. A warm-up phase is allowed in which the num- In 24 of the 37 microbenchmarks, XenoLinux performs simi-
larly to native Linux, tracking the uniprocessor Linux kernel per-
null null open slct sig sig fork exec sh TCP MTU 1500 TCP MTU 500
Config call I/O stat closeTCP inst hndl proc proc proc TX RX TX RX
L-SMP 0.53 0.81 2.10 3.51 23.2 0.83 2.94 143 601 4k2 Linux 897 897 602 544
L-UP 0.45 0.50 1.28 1.92 5.70 0.68 2.49 110 530 4k0 Xen 897 (-0%) 897 (-0%) 516 (-14%) 467 (-14%)
Xen 0.46 0.50 1.22 1.88 5.69 0.69 1.75 198 768 4k8 VMW 291 (-68%) 615 (-31%) 101 (-83%) 137 (-75%)
VMW 0.73 0.83 1.88 2.99 11.1 1.02 4.63 874 2k3 10k UML 165 (-82%) 203 (-77%) 61.1(-90%) 91.4(-83%)
UML 24.7 25.1 36.1 62.8 39.9 26.0 46.0 21k 33k 58k
Table 6: ttcp: Bandwidth in Mb/s
Table 3: lmbench: Processes - times in µs
2p 2p 2p 8p 8p 16p 16p
Config 0K 16K 64K 16K 64K 16K 64K 4.2.1 Network performance
L-SMP 1.69 1.88 2.03 2.36 26.8 4.79 38.4 In order to evaluate the overhead of virtualizing the network, we
L-UP 0.77 0.91 1.06 1.03 24.3 3.61 37.6 examine TCP performance over a Gigabit Ethernet LAN. In all ex-
Xen 1.97 2.22 2.67 3.07 28.7 7.08 39.4 periments we use a similarly-configured SMP box running native
VMW 18.1 17.6 21.3 22.4 51.6 41.7 72.2 Linux as one of the endpoints. This enables us to measure receive
UML 15.5 14.6 14.4 16.3 36.8 23.6 52.0 and transmit performance independently. The ttcp benchmark was
used to perform these measurements. Both sender and receiver ap-
Table 4: lmbench: Context switching times in µs plications were configured with a socket buffer size of 128kB, as
we found this gave best performance for all tested systems. The re-
Config 0K File 10K File Mmap Prot Page sults presented are a median of 9 experiments transferring 400MB.
create delete create delete lat fault fault Table 6 presents two sets of results, one using the default Ether-
L-SMP 44.9 24.2 123 45.2 99.0 1.33 1.88 net MTU of 1500 bytes, the other using a 500-byte MTU (chosen
L-UP 32.1 6.08 66.0 12.5 68.0 1.06 1.42 as it is commonly used by dial-up PPP clients). The results demon-
Xen 32.5 5.86 68.2 13.6 139 1.40 2.73 strate that the page-flipping technique employed by the XenoLinux
VMW 35.3 9.3 85.6 21.4 620 7.53 12.4 virtual network driver avoids the overhead of data copying and
UML 130 65.7 250 113 1k4 21.8 26.3 hence achieves a very low per-byte overhead. With an MTU of 500
bytes, the per-packet overheads dominate. The extra complexity of
Table 5: lmbench: File & VM system latencies in µs transmit firewalling and receive demultiplexing adversely impact
the throughput, but only by 14%.
VMware emulate a ‘pcnet32’ network card for communicating
with the guest OS which provides a relatively clean DMA-based
formance closely and outperforming the SMP kernel. In Tables 3
interface. ESX Server also supports a special ‘vmxnet’ driver for
to 5 we show results which exhibit interesting performance varia-
compatible guest OSes, which provides significant networking per-
tions among the test systems; particularly large penalties for Xen
formance improvements.
are shown in bold face.
In the process microbenchmarks (Table 3), Xen exhibits slower
fork, exec and sh performance than native Linux. This is expected, 4.3 Concurrent Virtual Machines
since these operations require large numbers of page table updates In this section, we compare the performance of running mul-
which must all be verified by Xen. However, the paravirtualization tiple applications in their own guest OS against running them on
approach allows XenoLinux to batch update requests. Creating new the same native operating system. Our focus is on the results us-
page tables presents an ideal case: because there is no reason to ing Xen, but we comment on the performance of the other VMMs
commit pending updates sooner, XenoLinux can amortize each hy- where applicable.
percall across 2048 updates (the maximum size of its batch buffer). Figure 4 shows the results of running 1, 2, 4, 8 and 16 copies
Hence each update hypercall constructs 8MB of address space. of the SPEC WEB99 benchmark in parallel on a two CPU ma-
Table 4 shows context switch times between different numbers chine. The native Linux was configured for SMP; on it we ran
of processes with different working set sizes. Xen incurs an ex- multiple copies of Apache as concurrent processes. In Xen’s case,
tra overhead between 1µs and 3µs, as it executes a hypercall to each instance of SPEC WEB99 was run in its own uniprocessor
change the page table base. However, context switch results for Linux guest OS (along with an sshd and other management pro-
larger working set sizes (perhaps more representative of real appli- cesses). Different TCP port numbers were used for each web server
cations) show that the overhead is small compared with cache ef- to enable the copies to be run in parallel. Note that the size of the
fects. Unusually, VMware Workstation is inferior to UML on these SPEC data set required for c simultaneous connections is (25 +
microbenchmarks; however, this is one area where enhancements (c × 0.66)) × 4.88 MBytes or approximately 3.3GB for 1000 con-
in ESX Server are able to reduce the overhead. nections. This is sufficiently large to thoroughly exercise the disk
The mmap latency and page fault latency results shown in Ta- and buffer cache subsystems.
ble 5 are interesting since they require two transitions into Xen per Achieving good SPEC WEB99 scores requires both high through-
page: one to take the hardware fault and pass the details to the guest put and bounded latency: for example, if a client request gets stalled
OS, and a second to install the updated page table entry on the guest due to a badly delayed disk read, then the connection will be classed
OS’s behalf. Despite this, the overhead is relatively modest. as non conforming and won’t contribute to the score. Hence, it is
One small anomaly in Table 3 is that XenoLinux has lower signal- important that the VMM schedules domains in a timely fashion. By
handling latency than native Linux. This benchmark does not re- default, Xen uses a 5ms time slice.
quire any calls into Xen at all, and the 0.75µs (30%) speedup is pre- In the case of a single Apache instance, the addition of a sec-
sumably due to a fortuitous cache alignment in XenoLinux, hence ond CPU enables native Linux to improve on the score reported
underlining the dangers of taking microbenchmarks too seriously. in section 4.1 by 28%, to 662 conformant clients. However, the
1001
3289
318
Aggregate score relative to single instance
1000 2.0
924
Aggregate number of conforming clients
906
896
290
289
887
880
874
282
-16.3% (non-SMP guest)
2833
842
2685
800
1.5
662
2104
600
1661
158
1.0
400
0.5
200
0 0.0
L X L X L X L X L X 1 2 4 8 8(diff) 1 2 4 8 8(diff)
1 2 4 8 16 OSDB-IR OSDB-OLTP
Simultaneous SPEC WEB99 Instances on Linux (L) and Xen(X) Simultaneous OSDB-IR and OSDB-OLTP Instances on Xen
Figure 4: SPEC WEB99 for 1, 2, 4, 8 and 16 concurrent Apache Figure 5: Performance of multiple instances of PostgreSQL
servers: higher values are better. running OSDB in separate Xen domains. 8(diff) bars show per-
formance variation with different scheduler weights.