Credit (also known as Credit1) is the default virtual CPU (vCPU) scheduler of the Xen hypervisor.
It is a general purpose, weighted fair-share scheduler.
Xen supports multiple schedulers. As said, Credit is the default, so it is used automatically, unless the
$SCHED different than
credit) parameter is passed to Xen via the bootloader.
Once the system is live, for creating a cpupool with Credit as its scheduler, either compile a cpupool configuration file, as described in
docs/man/xlcpupool.cfg.pod.5 (and as exemplified in
tools/examples/cpupool), or use just
xl cpupool-create name=\"pool1\" sched=\"credit\" cpus=[4,8]
Two kind of interactions with the scheduler are possible:
xl sched-credit -s
xl sched-credit -s -p pool1
xl sched-credit -s -t 20
xl sched-credit -d vm1
xl sched-credit -d vm1 -w 512
Implementation entirely lives in the hypervisor. Xen has a pluggable, hook based, architecture for schedulers. Thanks to this, Credit code is all contained in
In Credit, a vCPU has a priority, a status (i.e., active or inactive), a weight and some credits... and all these things interact in a rather involved way. Also, with years of use, things have gotten even more complex (due to, e.g., the introduction of boosting, caps and vCPU soft-affinity).
Dealing with such complexity is starting to be an issue. Odd behavior or subtle scheduling anomalies, that is not always possible to act upon, have been identified already. 
A certain lack of scalability and difficulties and weakness in dealing with mixed workloads and VMs with low latency requirements are other known problems.  For all these reasons, effort is ongoing to have Credit2 become the new default scheduler.
Any change to Credit code must to be tested by doing at least the following:
Ideally, all the above steps should also be performed in a configuration that includes cpupools, better if with pools using different schedulers, and by also doing the following:
|2016-10-14||1||Xen 4.8||Document written|