Difference between revisions of "Xen Project Schedulers"

From Xen
(Tidy up and restructure the 'historical xen scheduler' section)
(Updated the table)
Line 1: Line 1:
 
__TOC__
 
__TOC__
 
= Overview =
 
= Overview =
The Xen Project Hypervisor supports several different schedulers with different properties.
+
The Xen Project Hypervisor supports several different virtual CPU schedulers, with different properties.
   
  +
The job of an hypervisor's scheduler is to decide, among all the various vCPUs of the various virtual machines, which ones should execute on the host's physical CPUs (pCPUs), at any given point in time.
Different schedulers can be assigned to
 
* an entire host
 
* a [[Cpupools_Howto|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
+
Each schedulers can be assigned to
* an entire host
+
* the entire host,
  +
* a [[Cpupools_Howto|cpupool]] (i.e., basically, a group of physical CPUs)
* a CPU pool
 
  +
* A Virtual Machine
 
  +
[[File:Sched2.jpg|none|400px]]
<br>
 
  +
<gallery>
 
  +
More than one cpupool can be created, and each pool will have its own scheduler. IT is possible to use the ''same'' scheduler for more than one pool, but that means '''different''' instances of the same scheduling algorithm (and code) will be used in each pool.
File:Sched1.jpg
 
  +
File:Sched2.jpg
 
  +
Two kind of interactions with a scheduler are possible:
File:Sched3.jpg
 
  +
* checking or changing its global parameters,
</gallery>
 
  +
* checking or changing a VM's scheduling parameters.
  +
  +
[[File:Sched3.jpg|none|400px]]
  +
  +
= Currently Available Schedulers =
  +
  +
== The Credit Scheduler ==
  +
  +
[[Credit Scheduler|Credit]] is a general purpose, weighted fair share scheduler, and is the current default.
  +
  +
== The Credit2 Scheduler ==
  +
  +
[[Credit2 Scheduler Development|Credit2]] is the evolution of Credit, more scalable and better with latency sensitive workload, while still being based on a general purpose, weighted fair share, scheduling algorithm.
  +
  +
== The RTDS Scheduler ==
  +
  +
[[RTDS-Based-Scheduler|RTDS]] is a real-time scheduler, meant at supporting real-time workloads in the cloud, as well as embedded and mobile virtualization use cases.
  +
  +
== The ARINC653 Scheduler ==
  +
  +
[[ARINC653 Scheduler|ARINC653]] is an embedded (automotive and avionics) real-time scheduler.
  +
  +
= Use cases and Support in Xen 4.8 =
   
== Schedulers in Xen 4.5 and beyond ==
 
 
''Legend:''
 
''Legend:''
* {{Tick}} likely in 4.6
+
* {{Tick}} likely in 4.8
* {{HalfDone}} possible in 4.6
+
* {{HalfDone}} possible in 4.8
 
<br>
 
<br>
   
Line 27: Line 47:
 
!style="width: 15%;"|Scheduler
 
!style="width: 15%;"|Scheduler
 
!style="width: 30%;"|Use-cases
 
!style="width: 30%;"|Use-cases
!style="width: 15%;"|Xen 4.5
+
!style="width: 15%;"|Xen 4.7
!style="width: 30%;"|Plans for 4.6+
+
!style="width: 30%;"|Plans for 4.8+
 
|-
 
|-
 
|[[Credit_Scheduler|Credit]]
 
|[[Credit_Scheduler|Credit]]
 
|General Purpose
 
|General Purpose
 
|Supported<br>'''Default'''
 
|Supported<br>'''Default'''
|Supported
+
|{{Tick}}Supported<br>{{Tick}} '''Default'''
 
|-
 
|-
|[[Credit2_Scheduler_Development|Credit 2]]
+
|[[Credit2_Scheduler_Development|Credit2]]
 
|General Purpose<br>
 
|General Purpose<br>
Optimized for lower latency, high VM density
+
Optimized for low latency, scalability, high VM density
 
|Experimental
 
|Experimental
|{{Tick}} Supported<br>{{HalfDone}} '''Default'''
+
|{{HalfDone}} Supported
 
|-
 
|-
 
|[[RTDS-Based-Scheduler|RTDS]]
 
|[[RTDS-Based-Scheduler|RTDS]]
|Soft & Firm Real-time<br>Multicore<br>Embedded, Automotive, Graphics & Gaming in the Cloud, Low Latency Workloads
+
|Soft & Firm Real-time<br>Embedded, mobile & automotive<br>Graphics & Gaming in the Cloud
 
|Experimental
 
|Experimental
|{{Tick}} Hardening<br>{{Tick}} Optimization<br>{{Tick}} Better XL support<br>{{Tick}} <1μs granularity<br>{{HalfDone}} Supported
+
|{{Tick}} Improved xl support<br>{{Tick}} Experimental
 
|-
 
|-
 
|[[ARINC653_Scheduler|ARINC 653]]
 
|[[ARINC653_Scheduler|ARINC 653]]
|Hard Real-time <br>Single core<br>Avionics, Drones, Medical
+
|Hard Real-time <br>Avionics, Drones, Medical
|[http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg00972.html Supported?]<br>Compile time
+
|[http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg00972.html Supported?]
 
|{{Tick}} No change
 
|{{Tick}} No change
 
|}
 
|}
Line 81: Line 101:
 
* '''sched=''' boot parameter in [http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html Xen unstable boot options]
 
* '''sched=''' boot parameter in [http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html Xen unstable boot options]
 
* [[XL|xl]] [http://xenbits.xen.org/docs/unstable/man/xl.1.html#SCHEDULER-SUBCOMMANDS scheduler subcommands]
 
* [[XL|xl]] [http://xenbits.xen.org/docs/unstable/man/xl.1.html#SCHEDULER-SUBCOMMANDS scheduler subcommands]
* [[Credit Scheduler]]
 
* [[Credit2 Scheduler Development]]
 
* [[RTDS-Based-Scheduler]]
 
* [[ARINC653 Scheduler]]
 
 
* [[:Category:Scheduler]]
 
* [[:Category:Scheduler]]
 
* [[:Category:Resource Management]]
 
* [[:Category:Resource Management]]

Revision as of 16:49, 13 October 2016

Overview

The Xen Project Hypervisor supports several different virtual CPU schedulers, with different properties.

The job of an hypervisor's scheduler is to decide, among all the various vCPUs of the various virtual machines, which ones should execute on the host's physical CPUs (pCPUs), at any given point in time.

Each schedulers can be assigned to

  • the entire host,
  • a cpupool (i.e., basically, a group of physical CPUs)
Sched2.jpg

More than one cpupool can be created, and each pool will have its own scheduler. IT is possible to use the same scheduler for more than one pool, but that means different instances of the same scheduling algorithm (and code) will be used in each pool.

Two kind of interactions with a scheduler are possible:

  • checking or changing its global parameters,
  • checking or changing a VM's scheduling parameters.
Sched3.jpg

Currently Available Schedulers

The Credit Scheduler

Credit is a general purpose, weighted fair share scheduler, and is the current default.

The Credit2 Scheduler

Credit2 is the evolution of Credit, more scalable and better with latency sensitive workload, while still being based on a general purpose, weighted fair share, scheduling algorithm.

The RTDS Scheduler

RTDS is a real-time scheduler, meant at supporting real-time workloads in the cloud, as well as embedded and mobile virtualization use cases.

The ARINC653 Scheduler

ARINC653 is an embedded (automotive and avionics) real-time scheduler.

Use cases and Support in Xen 4.8

Legend:

  • likely in 4.8
  • possible in 4.8


Scheduler Use-cases Xen 4.7 Plans for 4.8+
Credit General Purpose Supported
Default
Supported
Default
Credit2 General Purpose

Optimized for low latency, scalability, high VM density

Experimental Supported
RTDS Soft & Firm Real-time
Embedded, mobile & automotive
Graphics & Gaming in the Cloud
Experimental Improved xl support
Experimental
ARINC 653 Hard Real-time
Avionics, Drones, Medical
Supported? No change

Historical Xen Schedulers

simple Earliest Deadline First (sEDF)

Quoting from sEDF (not any longer) in-tree documentation, "this scheduler provides weighted CPU sharing in an intuitive way and uses real-time algorithms to ensure time guarantees."

The real-time algorithm used was Earliest Deadline First (EDF), although it was modified for being used as a general purpose scheduler too. It could work in both work conserving and non-work conserving modes.

It was introduced in Xen 3.0, and was the default for a while. The scheduler was never properly adapted for dealing with SMP systems and multi vCPUs VMs. Both were working, but behavior and performance were unideal and unreliable. It was eventually removed from Xen 4.6.

Borrowed Virtual Time (BVT)

A virtual time based fair-share, general purpose, scheduler in use in Xen 2.0 and 3.0. Domains's shares of CPU time were determined by their weights. What it is traditionally called quantum, or timeslice, was known there as **context switch allowance**, and was configurable. It was SMP enabled, but lacked a non-work conserving mode.

Atropos

A soft real-time scheduler, capable of providing guarantees on the absolute shares of CPU time, and allowing using the slack on a best-effort basis. Of course (as it's always the case in RT schedulers) CPU slices were only really guaranteed in absence of CPU over-commitment.

It was in use in Xen 2.0.

Round Robin

It was... well... Round Robin! IT was there as a simple demonstration of Xen's internal scheduler API, not for real production use.

Also See