Xen Project Schedulers

From Xen
(Redirected from Scheduling in Xen)
Jump to: navigation, search



The Xen Project Hypervisor supports several different schedulers with different properties.

Different schedulers can be assigned to

  • an entire host
  • a pool of physical CPU’s on a host (VMs need to be assigned to a pool or pinned to a CPU)

Scheduler parameters can be modified per

  • an entire host
  • a CPU pool
  • A Virtual Machine

Schedulers in Xen 4.5 and beyond


  • likely in 4.6
  • possible in 4.6

Scheduler Use-cases Xen 4.5 Plans for 4.6+
Credit General Purpose Supported
Credit 2 General Purpose

Optimized for lower latency, high VM density

Experimental Supported
RTDS Soft & Firm Real-time
Embedded, Automotive, Graphics & Gaming in the Cloud, Low Latency Workloads
Experimental Hardening
Better XL support
<1μs granularity
ARINC 653 Hard Real-time
Single core
Avionics, Drones, Medical
Compile time
No change

Also See

History of Xen Schedulers

This content was originally compiled by Jacob Mathai.

1. Borrowed Virtual Time (Xen 2.0/3.0)

Global Parameters
ctx_allow - The context switch allowance is similar to the ''quantum'' in traditional schedulers. 
It is the minimum time that a scheduled domain will be allowed to run before being preempted.

Per-domain parameters
mcuadv - the MCU (Minimum Charging Unit) advance determines the proportional share of the CPU
that a domain receives. It is set inversely proportionally to a domain's sharing weight.
warp - the amount of `virtual time' the domain is allowed to warp backwards
warpl - the warp limit is the maximum time a domain can run warped for
warpu - the unwarp requirement is the minimum time a domain must run unwarped for before it can warp again

2. Atropos (Xen 2.0)

Atropos is a soft real time scheduler. It provides guarantees about absolute shares of the CPU, 
with a facility for sharing slack CPU time on a best-effort basis. It can provide timeliness 
guarantees for latency-sensitive domains.

Every domain has an associated period and slice. The domain should receive `slice' nanoseconds 
every `period' nanoseconds. This allows the administrator to configure both the absolute share 
of the CPU a domain receives and the frequency with which it is scheduled.

Note: don't over-commit the CPU when using Atropos (i.e. don't reserve more CPU than is 
available -- the utilization should be kept to slightly less than 100% in order to ensure predictable 

Per-domain parameters :
period - The regular time interval during which a domain is guaranteed to receive its allocation of CPU time.
slice - The length of time per period that a domain is guaranteed to run for (in the absence of voluntary yielding of the CPU).
latency - The latency hint is used to control how soon after waking up a domain it should be scheduled.
xtratime - This is a boolean flag that specifies whether a domain should be allowed a share of the system slack time.

3. Round Robin (Xen 2.0)

The round robin scheduler is included as a simple demonstration of Xen's internal scheduler 
API. It is not intended for production use.

Global Parameters
rr_slice - The maximum time each domain runs before the next scheduling decision is made.

4. sEDF scheduler (Xen 3.0)

(from docs/misc/sedf_scheduler_mini-HOWTO.txt)
This scheduler provides weighted CPU sharing in an intuitive way and uses realtime-algorithms 
to ensure time guarantees.

Per-domain parameters
use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
-period/slice are the normal EDF scheduling parameters in nanosecs
-latency-hint is the scaled period in case the domain is doing heavy I/O
(unused by the currently compiled version)
-extra is a flag (0/1), which controls whether the domain can run in extra-time
-weight is mutually exclusive with period/slice and specifies another way of setting a domains cpu slice
See wikipedia for a short intro to EDF:

5. ARINC 653 (Xen 4.1)

The arinc653 scheduler follows the ARINC 653 specification for scheduling, giving each partition (domain) a
fixed, dedicated time slot for execution.

Note: Current implementation does not support multicore, so 'maxcpus=1' must be set at boot.

System Calls and Scheduling

Some Scheduling System Calls
 *nice( )
getpriority( )
setpriority( )
sched_getscheduler( )
sched_setscheduler( )
sched_getparam( )
sched_setparam( )
sched_yield( )
sched_get_ priority_min( )
sched_get_ priority_max( )
sched_rr_get_interval( )

A related wiki topic on Real Time Applications & Preemption .

Personal tools