Upload
suzanna-richard
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
• virtual machines running on a Xen Project Hypervisor are known
as “domains”
• special domain known as dom0 is responsible for controlling the
hypervisor and starting other guest operating systems. These
• other guest operating systems are called domUs, this is because
these domains are “unprivileged” in the sense they cannot control
the hypervisor or start/stop other domains.
Consolidation
Virtual machine monitors enable server consolidation
Consolidated domains have wildly different workloads
Streaming Media Server
Voice-over-IP Server
Application Server
Web Server
Database Server
. . .
Virtualized Host
Guest Domain 1
Guest Domain 2
Guest Domain 3
Guest Domain 4
. . .
consolidation
Hypervisor – thin virtualization layer Driver Domain – hardware control Guest domains given restricted access
Xen Architecture
Hardware
DriverDomain
Xen ControlSoftware
Guest Domain
UserSoftware
GuestDomain
UserSoftware
GuestDomain
UserSoftware
Xen Hypervisor
Receiving a Network Packet
time
Hardware
DriverDomain
Xen ControlSoftware
Guest Domain
UserSoftware
GuestDomain
UserSoftware
GuestDomain
UserSoftware
Xen Hypervisor
Har
dwar
eIn
terr
upt
Virt
ual
Inte
rrup
t
Driv
er D
omai
n
Targ
et D
omai
n
Sche
dule
r
Sche
dule
r
Virt
ual
Inte
rrup
t
Pack
et A
rriv
es
Scheduler Fairness Virtual machine monitors must fairly support
both computation and I/O domains Xen supports computation domains well, but has
mixed results with I/O domains
The scheduler plays a significant role in I/O performance Improvements for I/O are not obvious Some of Xen’s current scheduler optimizations for
I/O are beneficial, others are not
Credits are assigned to each domain Approximate the fraction of processor resources
each domain will receive Do not indicate when each domain will receive its
fraction
Scheduler increments/decrements credits Periodically deducts credits from running domain Adds credits when majority of credits in the
system have been consumed
Xen’s Credit Scheduler
Scheduler Operation Domain states
Under – domain has credits remaining Over – domain is over its credit allowance
Domains are run in FIFO order by state Over domains only run if no under domains A domain may run for up to 30ms if it has enough credits
After running, return to the run queue by state Behind all other domains in the same state Regardless of runtime or remaining credits
This approach is biased against I/O
O2 O1
Run Queue
U4 U2U3Next domain
to runU1
Scheduler “Optimizations” for I/O I/O Domain Requirements
Low latency High bandwidth Independent of other domains’ workloads
“Optimizations” Boosting idle domains
Included in Xen Ordering the run queue by credits
Proposed for Xen Tickling the scheduler
Included in Xen
Boosting Idle Domains Initially, scheduler had no special features for
I/O domains
Additional scheduling state: boost Higher priority than under Used when an idle domain is sent a virtual interrupt
With boost
O2 O1 U1U4 U2U3
I1U5
O2 O1 U1U4 U2U3
I1B1
Next domainto run
Next domainto run
Impact of Boost Boost improves latency for I/O domains
0
50
100
150
200
250
300
350
400
Time
La
ten
cy
(m
s)
No Boost Boost
Ordering the Run Queue
• I/O domains tend to quickly block
• Within each state, sorts domains by credits remaining
• Short-running I/O domains are re-inserted near the head of the run queue
Impact of Ordering the Run Queue Ordering the run queue can reduce latency for
I/O domains under larger loads Surprisingly, often complements boost