https://wiki.xenproject.org/api.php?action=feedcontributions&user=Pennpanda&feedformat=atomXen - User contributions [en]2024-03-29T14:50:41ZUser contributionsMediaWiki 1.31.3https://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=17224RTDS-Based-Scheduler2016-08-14T16:02:55Z<p>Pennpanda: /* Citation */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
<br />
'''OPTIONS'''<br />
<br />
-d DOMAIN, --domain=DOMAIN<br />
Specify domain for which scheduler parameters are to be modified or retrieved. Mandatory for modifying scheduler parameters.<br />
<br />
-v VCPUID/all, --vcpuid=VCPUID/all<br />
Specify vcpu for which scheduler parameters are to be modified or retrieved.<br />
<br />
-p PERIOD, --period=PERIOD<br />
Period of time, in microseconds, over which to replenish the budget.<br />
<br />
-b BUDGET, --budget=BUDGET<br />
Amount of time, in microseconds, that the VCPU will be allowed to run every period.<br />
<br />
-c CPUPOOL, --cpupool=CPUPOOL<br />
Restrict output to domains in the specified cpupool.<br />
<br />
<br />
The details of how to use the '''xl sched-rtds''' command can be found by searching sched-rtds at this documentation[http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features Improved in Xen 4.7 ===<br />
<br />
* Burn budget in finer granularity instead of 1ms; <br />
* Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
* Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
<br />
=== Features In the Future ===<br />
* Work-conserving version of RTDS. Allow VCPUs (or VMs) to use (unreserved) idle time left in the system.<br />
* Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Citation===<br />
Please cite our [https://www.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf research paper] below if you use RTDS for a publication.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=17223RTDS-Based-Scheduler2016-08-14T16:02:29Z<p>Pennpanda: Add citation note</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
<br />
'''OPTIONS'''<br />
<br />
-d DOMAIN, --domain=DOMAIN<br />
Specify domain for which scheduler parameters are to be modified or retrieved. Mandatory for modifying scheduler parameters.<br />
<br />
-v VCPUID/all, --vcpuid=VCPUID/all<br />
Specify vcpu for which scheduler parameters are to be modified or retrieved.<br />
<br />
-p PERIOD, --period=PERIOD<br />
Period of time, in microseconds, over which to replenish the budget.<br />
<br />
-b BUDGET, --budget=BUDGET<br />
Amount of time, in microseconds, that the VCPU will be allowed to run every period.<br />
<br />
-c CPUPOOL, --cpupool=CPUPOOL<br />
Restrict output to domains in the specified cpupool.<br />
<br />
<br />
The details of how to use the '''xl sched-rtds''' command can be found by searching sched-rtds at this documentation[http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features Improved in Xen 4.7 ===<br />
<br />
* Burn budget in finer granularity instead of 1ms; <br />
* Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
* Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
<br />
=== Features In the Future ===<br />
* Work-conserving version of RTDS. Allow VCPUs (or VMs) to use (unreserved) idle time left in the system.<br />
* Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Citation===<br />
Please cite our [https://www.cis.upenn.edu/~linhphan/papers/emsoft14-rt-xen.pdf research paper] below if you use RTDS for a publication.<br />
<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=17222RTDS-Based-Scheduler2016-08-14T16:01:50Z<p>Pennpanda: /* Features In the Future */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
<br />
'''OPTIONS'''<br />
<br />
-d DOMAIN, --domain=DOMAIN<br />
Specify domain for which scheduler parameters are to be modified or retrieved. Mandatory for modifying scheduler parameters.<br />
<br />
-v VCPUID/all, --vcpuid=VCPUID/all<br />
Specify vcpu for which scheduler parameters are to be modified or retrieved.<br />
<br />
-p PERIOD, --period=PERIOD<br />
Period of time, in microseconds, over which to replenish the budget.<br />
<br />
-b BUDGET, --budget=BUDGET<br />
Amount of time, in microseconds, that the VCPU will be allowed to run every period.<br />
<br />
-c CPUPOOL, --cpupool=CPUPOOL<br />
Restrict output to domains in the specified cpupool.<br />
<br />
<br />
The details of how to use the '''xl sched-rtds''' command can be found by searching sched-rtds at this documentation[http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features Improved in Xen 4.7 ===<br />
<br />
* Burn budget in finer granularity instead of 1ms; <br />
* Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
* Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
<br />
=== Features In the Future ===<br />
* Work-conserving version of RTDS. Allow VCPUs (or VMs) to use (unreserved) idle time left in the system.<br />
* Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16965Install-multiple-versions2016-05-25T20:30:00Z<p>Pennpanda: /* How to install two versions of Xen on the same host */</p>
<hr />
<div>=Purpose of this page=<br />
Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
=Notations and Assumptions=<br />
<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
=How to install two versions of Xen on the same host=<br />
<br />
'''Step 1:''' Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
'''Step 2:''' Configure the grub entry for each version of Xen. <br />
<br />
'''Step 3:''' Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
<br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
<br />
cd ${INSTALL46}<br />
<br />
./sbin/xl list<br />
<br />
'''NB:''' If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
<br />
cd ${INSTALL46}<br />
<br />
./lib/xen/bin/xen-init-dom0<br />
<br />
=Reference=<br />
[1] Question about the best practice to install two versions of Xen toolstack on the same machine. http://www.gossamer-threads.com/lists/xen/devel/432095</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16964Install-multiple-versions2016-05-25T20:29:49Z<p>Pennpanda: /* How to install two versions of Xen on the same host */</p>
<hr />
<div>=Purpose of this page=<br />
Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
=Notations and Assumptions=<br />
<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
=How to install two versions of Xen on the same host=<br />
<br />
'''Step 1:''' Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
'''Step 2:''' Configure the grub entry for each version of Xen. <br />
<br />
'''Step 3:''' Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
<br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
<br />
cd ${INSTALL46}<br />
<br />
./sbin/xl list<br />
<br />
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
<br />
cd ${INSTALL46}<br />
<br />
./lib/xen/bin/xen-init-dom0<br />
<br />
=Reference=<br />
[1] Question about the best practice to install two versions of Xen toolstack on the same machine. http://www.gossamer-threads.com/lists/xen/devel/432095</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16963Install-multiple-versions2016-05-25T20:29:34Z<p>Pennpanda: /* How to install two versions of Xen on the same host */</p>
<hr />
<div>=Purpose of this page=<br />
Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
=Notations and Assumptions=<br />
<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
=How to install two versions of Xen on the same host=<br />
<br />
'''Step 1:''' Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
'''Step 2:''' Configure the grub entry for each version of Xen. <br />
<br />
'''Step 3:''' Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
<br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
<br />
cd ${INSTALL46}<br />
<br />
./sbin/xl list<br />
<br />
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
<br />
cd ${INSTALL46}<br />
<br />
./lib/xen/bin/xen-init-dom0<br />
<br />
Reference<br />
[1] Question about the best practice to install two versions of Xen toolstack on the same machine. http://www.gossamer-threads.com/lists/xen/devel/432095</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16962Install-multiple-versions2016-05-25T20:26:30Z<p>Pennpanda: /* Notations and Assumptions */</p>
<hr />
<div>=Purpose of this page=<br />
Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
=Notations and Assumptions=<br />
<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
=How to install two versions of Xen on the same host=<br />
<br />
'''Step 1:''' Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
'''Step 2:''' Configure the grub entry for each version of Xen. <br />
<br />
'''Step 3:''' Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
cd ${INSTALL46}<br />
./sbin/xl list<br />
<br />
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
cd ${INSTALL46}<br />
./lib/xen/bin/xen-init-dom0</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16961Install-multiple-versions2016-05-25T20:26:07Z<p>Pennpanda: </p>
<hr />
<div>=Purpose of this page=<br />
Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
=Notations and Assumptions=<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
=How to install two versions of Xen on the same host=<br />
<br />
'''Step 1:''' Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
'''Step 2:''' Configure the grub entry for each version of Xen. <br />
<br />
'''Step 3:''' Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
cd ${INSTALL46}<br />
./sbin/xl list<br />
<br />
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
cd ${INSTALL46}<br />
./lib/xen/bin/xen-init-dom0</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16960Install-multiple-versions2016-05-25T20:25:31Z<p>Pennpanda: </p>
<hr />
<div>=Purpose of this page=<br />
Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
=Assumptions=<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
'''Step 1:''' Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
'''Step 2:''' Configure the grub entry for each version of Xen. <br />
<br />
'''Step 3:''' Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
cd ${INSTALL46}<br />
./sbin/xl list<br />
<br />
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
cd ${INSTALL46}<br />
./lib/xen/bin/xen-init-dom0</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16959Install-multiple-versions2016-05-25T20:23:57Z<p>Pennpanda: </p>
<hr />
<div>=== Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
Assumptions<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
Step 1: Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
Step 2: Configure the grub entry for each version of Xen. <br />
<br />
Step 3: Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
cd ${INSTALL46}<br />
./sbin/xl list<br />
<br />
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
cd ${INSTALL46}<br />
./lib/xen/bin/xen-init-dom0</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Install-multiple-versions&diff=16958Install-multiple-versions2016-05-25T20:23:32Z<p>Pennpanda: Created page with "Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kern..."</p>
<hr />
<div>Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.<br />
<br />
This wiki will describe how to use two different versions of Xen on the same host.<br />
<br />
Assumptions<br />
This wiki assumes Ubuntu 12.04 as dom0.<br />
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;<br />
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;<br />
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;<br />
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;<br />
<br />
Step 1: Install two versions of the Xen kernel under /boot; <br />
You just need to install the two xen kernels into /boot on the host;<br />
<br />
The commands to install one version of Xen kernel are as follows:<br />
<br />
cd ${SRC46}<br />
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
cd ${SRC47}<br />
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath<br />
make<br />
sudo make install-xen <br />
<br />
Step 2: Configure the grub entry for each version of Xen. <br />
<br />
Step 3: Install Xen toolstack into the installation folder for each version:<br />
cd ${SRC46}<br />
make install-tools <br />
<br />
cd ${SRC47}<br />
make install-tools <br />
<br />
Now you have install two versions of Xen kernels and Xen toolstacks into your host. <br />
<br />
You can reboot your system and select one version, say, Xen 4.6.0.<br />
<br />
The version of Xen toolstack has to match with the version of Xen kernel you are using. <br />
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.<br />
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.<br />
cd ${INSTALL46}<br />
./sbin/xl list<br />
<br />
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:<br />
cd ${INSTALL46}<br />
./lib/xen/bin/xen-init-dom0</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=16929RTDS-Based-Scheduler2016-05-10T18:35:07Z<p>Pennpanda: /* Features Improved in Xen 4.7 */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
<br />
'''OPTIONS'''<br />
<br />
-d DOMAIN, --domain=DOMAIN<br />
Specify domain for which scheduler parameters are to be modified or retrieved. Mandatory for modifying scheduler parameters.<br />
<br />
-v VCPUID/all, --vcpuid=VCPUID/all<br />
Specify vcpu for which scheduler parameters are to be modified or retrieved.<br />
<br />
-p PERIOD, --period=PERIOD<br />
Period of time, in microseconds, over which to replenish the budget.<br />
<br />
-b BUDGET, --budget=BUDGET<br />
Amount of time, in microseconds, that the VCPU will be allowed to run every period.<br />
<br />
-c CPUPOOL, --cpupool=CPUPOOL<br />
Restrict output to domains in the specified cpupool.<br />
<br />
<br />
The details of how to use the '''xl sched-rtds''' command can be found by searching sched-rtds at this documentation[http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features Improved in Xen 4.7 ===<br />
<br />
* Burn budget in finer granularity instead of 1ms; <br />
* Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
* Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
=== Features In the Future ===<br />
* Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make <br />
domU have less budget than it requires.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=16928RTDS-Based-Scheduler2016-05-10T18:34:52Z<p>Pennpanda: /* Features developed in Xen 4.7 */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
<br />
'''OPTIONS'''<br />
<br />
-d DOMAIN, --domain=DOMAIN<br />
Specify domain for which scheduler parameters are to be modified or retrieved. Mandatory for modifying scheduler parameters.<br />
<br />
-v VCPUID/all, --vcpuid=VCPUID/all<br />
Specify vcpu for which scheduler parameters are to be modified or retrieved.<br />
<br />
-p PERIOD, --period=PERIOD<br />
Period of time, in microseconds, over which to replenish the budget.<br />
<br />
-b BUDGET, --budget=BUDGET<br />
Amount of time, in microseconds, that the VCPU will be allowed to run every period.<br />
<br />
-c CPUPOOL, --cpupool=CPUPOOL<br />
Restrict output to domains in the specified cpupool.<br />
<br />
<br />
The details of how to use the '''xl sched-rtds''' command can be found by searching sched-rtds at this documentation[http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features Improved in Xen 4.7 ===<br />
<br />
* Burn budget in finer granularity instead of 1ms; <br />
* Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
* Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
<br />
=== Features In the Future ===<br />
* Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make <br />
domU have less budget than it requires.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=16927RTDS-Based-Scheduler2016-05-10T18:29:36Z<p>Pennpanda: /* Usage */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
<br />
'''OPTIONS'''<br />
<br />
-d DOMAIN, --domain=DOMAIN<br />
Specify domain for which scheduler parameters are to be modified or retrieved. Mandatory for modifying scheduler parameters.<br />
<br />
-v VCPUID/all, --vcpuid=VCPUID/all<br />
Specify vcpu for which scheduler parameters are to be modified or retrieved.<br />
<br />
-p PERIOD, --period=PERIOD<br />
Period of time, in microseconds, over which to replenish the budget.<br />
<br />
-b BUDGET, --budget=BUDGET<br />
Amount of time, in microseconds, that the VCPU will be allowed to run every period.<br />
<br />
-c CPUPOOL, --cpupool=CPUPOOL<br />
Restrict output to domains in the specified cpupool.<br />
<br />
<br />
The details of how to use the '''xl sched-rtds''' command can be found by searching sched-rtds at this documentation[http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features developed in Xen 4.7 ===<br />
<br />
* (done) Burn budget in finer granularity instead of 1ms; <br />
* (done) Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
*Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
* (done) Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=16926RTDS-Based-Scheduler2016-05-10T18:28:33Z<p>Pennpanda: /* Usage */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
<br />
'''OPTIONS'''<br />
<br />
-d DOMAIN, --domain=DOMAIN<br />
Specify domain for which scheduler parameters are to be modified or retrieved. Mandatory for modifying scheduler parameters.<br />
<br />
-v VCPUID/all, --vcpuid=VCPUID/all<br />
Specify vcpu for which scheduler parameters are to be modified or retrieved.<br />
<br />
-p PERIOD, --period=PERIOD<br />
Period of time, in microseconds, over which to replenish the budget.<br />
<br />
-b BUDGET, --budget=BUDGET<br />
Amount of time, in microseconds, that the VCPU will be allowed to run every period.<br />
<br />
-c CPUPOOL, --cpupool=CPUPOOL<br />
Restrict output to domains in the specified cpupool.<br />
<br />
<br />
The details of how to use the '''xl sched-rtds''' command can be found by [searching sched-rtds at this documentation][http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features developed in Xen 4.7 ===<br />
<br />
* (done) Burn budget in finer granularity instead of 1ms; <br />
* (done) Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
*Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
* (done) Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=16925RTDS-Based-Scheduler2016-05-10T18:27:33Z<p>Pennpanda: /* Usage */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
The options for the '''xl sched-rtds''' command can be found by [searching sched-rtds at this documentation][http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS].<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features developed in Xen 4.7 ===<br />
<br />
* (done) Burn budget in finer granularity instead of 1ms; <br />
* (done) Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
*Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
* (done) Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=RTDS-Based-Scheduler&diff=16924RTDS-Based-Scheduler2016-05-10T18:24:39Z<p>Pennpanda: /* Introduction */</p>
<hr />
<div>{{InfoLeft|The scheduler has been included as an experimental in Xen 4.5 and is still an in-development feature.}}<br />
<br />
==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler. The RTDS scheduler in Xen 4.7 changes the scheduling model from the quantum-driven to event-driven. Because the event-driven model can avoid invoking the scheduler unnecessarily, it will incur less scheduling overhead.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
TO DO: include the new per-vcpu usage<br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
<br />
In Xen 4.7, budget replenishment and enforcement are separated by adding a replenishment timer, which fires at the next most imminent<br />
release time of all runnable vcpus.<br />
<br />
A replenishment queue has been added to keep track of all replenishment events.<br />
<br />
The following functions have major changes to manage the replenishment events and timer.<br />
<br />
repl_handler(): It is a timer handler which is re-programmed to fire at the nearest vcpu deadline to replenish vcpus.<br />
<br />
rt_schedule(): picks the highest runnable vcpu based on cpu affinity and ret.time will be passed to schedule(). If an idle<br />
vcpu is picked, -1 is returned to avoid busy-waiting.<br />
<br />
repl_update() has been removed.<br />
<br />
rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of picking one from the run queue.<br />
<br />
rt_context_saved(): when context switching is finished, the preempted vcpu will be put back into the run queue and it tickles.<br />
<br />
Simplified funtional graph:<br />
<br />
schedule.c SCHEDULE_SOFTIRQ:<br />
rt_schedule():<br />
[spin_lock]<br />
burn_budget(scurr)<br />
snext = runq_pick()<br />
[spin_unlock]<br />
<br />
sched_rt.c TIMER_SOFTIRQ<br />
replenishment_timer_handler()<br />
[spin_lock]<br />
<for_each_vcpu_on_q(i)> {<br />
replenish(i)<br />
}><br />
runq_tickle()<br />
program_timer()<br />
[spin_lock]<br />
<br />
=== Features developed in Xen 4.7 ===<br />
<br />
* (done) Burn budget in finer granularity instead of 1ms; <br />
* (done) Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
*Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
* (done) Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Scheduler]]<br />
[[Category:Resource Management]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Xen_4.7_RC_test_instructions&diff=16782Xen 4.7 RC test instructions2016-05-09T17:11:44Z<p>Pennpanda: /* RTDS scheduler improvements */</p>
<hr />
<div>{{InfoLeft|If you come to this page before or after the Test Day is completed, your testing is still valuable, and you can use the information on this page to test, post any bugs and test reports to xen-devel@. If this page is more than two weeks old when you arrive here, please check the [[Xen Project Test Days|current schedule]] and see if a similar but more recent Test Day is planned or has already happened.<br />
}}<br />
<br />
= What needs to be tested =<br />
<br />
General things:<br />
* Making sure that Xen 4.7 compiles and installs properly on different software configurations; particularly on distros<br />
* Making sure that Xen 4.7, along with appropriately up-to-date kernels, work on different hardware. <br />
<br />
For more ideas about what to test, please see [[Testing_Xen|Testing Xen]].<br />
<br />
== ARM Smoke Testing ==<br />
If you use ARM Hardware, which is not widely available or not rackable (and thus not part of our automated test suite), please check out [[Xen ARM Manual Smoke Test]]. Helping out to manually test ARM boards (which will only take a few minutes) will guarantee that Xen 4.7 will work on the board that you use. If you want to see which boards need testing, check [[Xen ARM Manual Smoke Test/Results]].<br />
<br />
= Installing =<br />
<br />
== Getting a RC ==<br />
For the expressions/examples below, set the following bash/sh/... variable to the release candidate number (e.g. one of <code>rc1</code>, <code>rc2</code>, ... )<br />
<br />
RC="<release candidate number>"<br />
<br />
=== From xen.git ===<br />
With a recent enough <code>git</code> (>= 1.7.8.2), just pull from the proper tag (<code>4.7.0-$RC</code>) from the main repo directly:<br />
git clone -b 4.7.0-$RC git://xenbits.xen.org/xen.git<br />
<br />
With an older <code>git</code> version (and/or if that does not work, e.g., complaining with a message like this: <code>Remote branch 4.7.0-$RC not found in upstream origin, using HEAD instead</code>), do the following:<br />
git clone git://xenbits.xen.org/xen.git ; cd xen ; git checkout 4.7.0-$RC<br />
<br />
=== From tarball ===<br />
<br />
Download:<br />
http://bits.xensource.com/oss-xen/release/4.7.0-$RC/xen-4.7.0-$RC.tar.gz <br />
http://bits.xensource.com/oss-xen/release/4.7.0-$RC/xen-4.7.0-$RC.tar.gz.sig<br />
<br />
== Building == <br />
<br />
Instructions are available for building Xen on [[Compiling_Xen_From_Source|Linux]], [[Compiling_Xen_From_Source_on_NetBSD|NetBSD]], and [[FreeBSD_Dom0|FreeBSD]]<br />
<br />
= Known issues =<br />
<br />
== RC1 ==<br />
* [http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00346.html XSM denials with 4.7.0 RC1]<br />
* [http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00225.html Regression in Xen 4.7-rc1 - can't boot HVM guests with more than 64 vCPUS] (this is caused by a [http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00379.html bug in the Linux kernel], not a bug in Xen)<br />
<br />
= Test instructions =<br />
<br />
== General ==<br />
* Remove any old versions of Xen toolstack and userspace binaries (including <code>qemu</code>).<br />
* Remove any udev files under /etc because Xen 4.7 doesn't use those anymore.<br />
* Download and install the most recent Xen 4.7 RC, as described above. Make sure to check the <code>README</code> and <code>INSTALL</code> for changes in required development libraries and procedures. Some particular things to note:<br />
<br />
Once you have Xen 4.7 RC installed check that you can install a guest etc and use it in the ways which you normally would, i.e. that your existing guest configurations, scripts etc still work.<br />
<br />
=== USB Support for xl ===<br />
{{TODOLeft|<br />
* This section was not written by the author of the relevant features. Thus there may be inaccuracies<br />
* Someone needs to go through [[Xen_USB_Passthrough#PVUSB|PVUSB]] and [[Xen_USB_Passthrough#PVUSB_in_xl.2Flibxl|PVUSB in xl]] and update it.<br />
* Any limitations need to be documented (e.g. are there any bits and pieces pending in QEMU - is "qusb" expected to work or not yet)?<br />
}}<br />
<br />
[[xl]] introduces PVUSB support as well as the following [http://xenbits.xen.org/docs/4.6-testing/man/xl.1.html#PCI-PASS-THROUGH commands]: <br />
<code><br />
usbctrl-attach<br />
usbctrl-detach <br />
usbdev-attach<br />
usbdev-detach <br />
usb-list<br />
</code><br />
which corresponds to <br />
<code><br />
usbctrl=[ "USBCTRL_SPEC_STRING", "USBCTRL_SPEC_STRING", ... ]<br />
usbdev=[ "USB_SPEC_STRING", "USB_SPEC_STRING", ... ]<br />
</code><br />
as outlined in the [http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html xl.cfg(5)] man page.<br />
<br />
=== RTDS scheduler improvements ===<br />
<br />
The RTDS scheduler was improved in the following way<br />
* The RTDS scheduler has been changed from a quantum-driven model to an event-driven model, which will not invoke the scheduler unnecessarily: if you use this scheduler, you may want to test your workload using the RC and check whether there are any unexpected side effects<br />
* Support to get/set per-VCPU parameters have been added to the RTDS toolstack: see [http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS search for sched-rtds]<br />
** The <code>-v VCPUID/all, --vcpuid=VCPUID/all</code> options have been added<br />
<br />
=== <code>-f</code> option for <code>xl vcpu-pin</code> ===<br />
In order to be able to undo a vcpu pin override in case of a kernel driver error add a flag "-f" to the "xl vcpu-pin" command forcing the hypervisor to undo the override.<br />
<br />
Also see [http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS xl(1) search for vcpu-pin]<br />
<br />
== Specific ARM Test Instructions ==<br />
<br />
Follow<br />
[[Xen_ARM_with_Virtualization_Extensions]] and [[Xen_ARM_with_Virtualization_Extensions#Testing]]<br />
<br />
=== TODO: Add headline for specific thing to test ===<br />
<br />
Xen 4.7 supports ... <new feature><br />
<br />
<Add some instructions on how to test the new feature><br />
<br />
== Specific x86 Test Instructions ==<br />
<br />
=== Intel Code and Data Prioritization (CDP) === <br />
<br />
{{TODOLeft|<br />
* This section was not written by the author of the relevant features. Thus there may be inaccuracies<br />
* Maybe some instructions on what to test and what one expects to see<br />
}}<br />
<br />
Code and Data Prioritization (CDP) Technology is an extension of CAT, which is available on Intel Broadwell and later server platforms. CDP enables isolation and separate prioritization of code and data fetches to the L3 cache in a software configurable manner, which can enable workload prioritization and tuning of cache capacity to the characteristics of the workload. CDP extends Cache Allocation Technology (CAT) by providing separate code and data masks per Class of Service (COS).<br />
<br />
For more information see:<br />
* [http://xenbits.xen.org/docs/unstable/man/xl.1.html#CACHE-ALLOCATION-TECHNOLOGY xl man page (CACHE-ALLOCATION-TECHNOLOGY)]<br />
* [http://xenbits.xen.org/docs/unstable/misc/xl-psr.html xl-psr]<br />
* [[Intel Platform QoS Technologies]]<br />
<br />
=== COLO - Coarse Grain Lock Stepping ===<br />
{{TODOLeft|<br />
* This section was not written by the author of the relevant features. Thus there may be inaccuracies<br />
* Are there any restrictions / portions which have not yet been upstreamed? <br />
* Maybe some instructions on what to test and what one expects to see<br />
* Relevant man pages<br />
** [http://xenbits.xen.org/docs/unstable/man/xl.1.html#DOMAIN-SUBCOMMANDS xl(1) search for Remus]<br />
** [http://xenbits.xen.org/docs/unstable/man/xl.conf.5.html xl.conf(5) search for colo.default.proxyscript]<br />
* Relevant Other pages<br />
** [[COLO - Coarse Grain Lock Stepping]]<br />
}}<br />
<br />
=== TODO: Add headline for specific thing to test ===<br />
<br />
Xen 4.7 supports ... <new feature><br />
<br />
<Add some instructions on how to test the new feature><br />
<br />
<br />
{{Anchor|RC}}<br />
<br />
== RC specific things to test ==<br />
=== RC2 ===<br />
<br />
* XSM and driver domain: start xl devd in driver domain, and see if there is XSM denial message shown in xl dmesg.<br />
<br />
= Reporting Bugs (& Issues) =<br />
<br />
* Use Freenode IRC channel #xentest to discuss questions interactively<br />
* Report any bugs / missing functionality / unexpected results. <br />
* Please put '''[TestDay]''' into the subject line<br />
* Also make sure you specify the RC number you are using<br />
* Make sure to follow the guidelines on [[Reporting Bugs against Xen]] (please CC the relevant maintainers and the Release Manager - wei dot liu2 at citrix dot com).<br />
<br />
= Reporting success =<br />
<br />
We would love it if you could report successes by e-mailing <code>xen-devel@lists.xen.org</code>, preferably including:<br />
* '''Hardware''': Please at least include the processor manufacturer (Intel/AMD). Other helpful information might include specific processor models, amount of memory, number of cores, and so on<br />
* '''Software''': If you're using a distro, the distro name and version would be the most helpful. Other helpful information might include the kernel that you're running, or other virtualization-related software you're using (e.g., libvirt, xen-tools, drbd, &c).<br />
* '''Guest operating systems''': If running a Linux version, please specify whether you ran it in PV or HVM mode.<br />
* '''Functionality tested''': High-level would include toolstacks, and major functionality (e.g., suspend/resume, migration, pass-through, stubdomains, &c)<br />
<br />
The following template might be helpful: should you use <code>Xen 4.7.0-<Some RC></code>''' for testing, please make sure you state that information!<br />
<pre><br />
Subject: [TESTDAY] Test report<br />
<br />
* Hardware:<br />
<br />
* Software:<br />
<br />
* Guest operating systems:<br />
<br />
* Functionality tested:<br />
<br />
* Comments:<br />
</pre><br />
<br />
For example:<br />
<pre><br />
Subject: [TESTDAY] Test report<br />
<br />
* Hardware: <br />
Dell 390's (Intel, dual-core) x15<br />
HP (AMD, quad-core) x5<br />
<br />
* Software: <br />
Ubuntu 10.10,11.10<br />
Fedora 17<br />
<br />
* Guest operating systems:<br />
Windows 8<br />
Ubuntu 12.10,11.10 (HVM)<br />
Fedora 17 (PV)<br />
<br />
* Functionality tested:<br />
xl<br />
suspend/resume<br />
pygrub<br />
<br />
* Comments:<br />
Window 8 booting seemed a little slower than normal.<br />
<br />
Other than that, great work!<br />
</pre><br />
<br />
[[Category:Xen_4.7]] <br />
[[Category:Xen]]<br />
[[Category:Community]]<br />
[[Category:Events]]<br />
[[Category:Test Day]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=Archived/Developer_Meeting/Aug2015&diff=15235Archived/Developer Meeting/Aug20152015-08-08T18:34:46Z<p>Pennpanda: </p>
<hr />
<div>{{InfoLeft|Please add yourself to the list if you want to attend and add a topic you want to cover. Please make sure you get wiki edit rights (see below).}}<br />
{{WarningLeft|The Xen Wiki has been subject to sustained severe spam attacks in the last few months. To solve this and keep the wiki usable for everyone, we had to lock down the wiki and create an editors group. CAPTCHAs dp not appear to work against the spam attacks we have seen. Until we have a solution in place, please [http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html fill out this form] and we will add you to the editors group.}}<br />
<br />
== When and Where ? ==<br />
August 19, 2015 from 10:00-13:30<br><br><br />
<br />
Exact room to be announced<br><br />
Sheraton Seattle Hotel<br><br />
1400 6th Ave<br><br />
Seattle, WA<br><br />
USA<br />
<br />
Lunch and break will be provided<br />
<br />
== Topics to Discuss at the Developer Meeting ==<br />
=== Instructions ===<br />
Please reply to this [http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03138.html thread] or by update this wiki page<br />
<br />
=== Topics ===<br />
<br />
* PVH Next Steps (Konrad)<br />
* XSplice Design - Loose Ends and Decisions (Konrad)<br />
* Xen 4.6 retrospective and concrete process improvements (see [http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg00173.html here])<br />
<br />
== Confirmed Attendees ==<br />
{{InfoLeft|Please Add yourself to the list. Note that we have space for '''30 people''' only.}}<br />
* Lars Kurth, Citrix <br />
* Dario Faggioli, Citrix<br />
* Jürgen Groß, SUSE<br />
* Julien Grall, Citrix<br />
* Andrew Cooper, Citrix<br />
* Anil Madhavapeddy, Cambridge University<br />
* Wei Liu, Citrix<br />
* Jim Fehlig, SUSE<br />
* Stefano Stabellini, Citrix<br />
* Meng Xu, University of Pennsylvania<br />
[[Category:Project]]<br />
[[Category:Community]]<br />
[[Category:Events]]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13444User:Pennpanda2014-12-19T17:08:18Z<p>Pennpanda: /* TODO */</p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
'''[WARN]''' The scheduler has been included as an experimental and in-development feature.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===TODO===<br />
The following features will be implemented after Xen 4.5:<br />
<br />
*Burn budget in finer granularity instead of 1ms; <br />
*Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then;<br />
*Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires.<br />
*Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13443User:Pennpanda2014-12-19T17:07:54Z<p>Pennpanda: /* TODO */</p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
'''[WARN]''' The scheduler has been included as an experimental and in-development feature.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===TODO===<br />
The following features will be implemented after Xen 4.5:<br />
<br />
*Burn budget in finer granularity instead of 1ms; [medium]<br />
*Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then [medium]<br />
*Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires. [not sure about difficulty right now] <br />
*Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13442User:Pennpanda2014-12-19T17:07:27Z<p>Pennpanda: /* TODO */</p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
'''[WARN]''' The scheduler has been included as an experimental and in-development feature.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===TODO===<br />
The following features will be implemented after Xen 4.5:<br />
# Burn budget in finer granularity instead of 1ms; [medium]<br />
# Use separate timer per VCPU for each VCPU's budget replenishment, instead of scanning the full runqueue every now and then [medium]<br />
# Handle time stolen from domU by hypervisor. When it runs on a machine with many sockets and lots of cores, the spin-lock for global RunQ used in rtds scheduler could eat up time from domU, which could make domU have less budget than it requires. [not sure about difficulty right now] <br />
# Toolstack supports assigning/display each VCPU's parameters of each domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13441User:Pennpanda2014-12-19T17:07:01Z<p>Pennpanda: </p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
'''[WARN]''' The scheduler has been included as an experimental and in-development feature.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===TODO===<br />
The following features will be implemented after Xen 4.5<br />
# Burn budget in finer granularity instead of 1ms; [medium]<br />
# Use separate timer per VCPU for each VCPU's budget replenishment, <br />
instead of scanning the full runqueue every now and then [medium]<br />
# Handle time stolen from domU by hypervisor. When it runs on a machine <br />
with many sockets and lots of cores, the spin-lock for global RunQ used in rtds <br />
scheduler could eat up time from domU, which could make domU have less budget <br />
than it requires. [not sure about difficulty right now] <br />
# Toolstack supports assigning/display each VCPU's parameters of each <br />
domain.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM/domU''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13440User:Pennpanda2014-12-19T17:04:15Z<p>Pennpanda: /* Introduction */</p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
'''[WARN]''' The scheduler has been included as an experimental and in-development feature.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13439User:Pennpanda2014-12-19T17:04:02Z<p>Pennpanda: /* Introduction */</p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
['''WARN'''] The scheduler has been included as an experimental and in-development feature.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13438User:Pennpanda2014-12-19T17:03:53Z<p>Pennpanda: /* Introduction */</p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
[WARN] The scheduler has been included as an experimental and in-development feature.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13437User:Pennpanda2014-12-19T17:02:02Z<p>Pennpanda: </p>
<hr />
<div>==Real-Time-Deferrable-Server(RTDS)-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13436User:Pennpanda2014-12-19T17:01:39Z<p>Pennpanda: </p>
<hr />
<div>=RTDS CPU Scheduler=<br />
==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13435User:Pennpanda2014-12-19T17:00:29Z<p>Pennpanda: /* Usage */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The '''xl sched-rtds''' command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13434User:Pennpanda2014-12-19T17:00:12Z<p>Pennpanda: /* Description */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with <budget>, <period> is supposed to run for <budget>us (not necessarily continuously) in every <period>us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13433User:Pennpanda2014-12-19T16:58:59Z<p>Pennpanda: /* Introduction */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to guest VMs on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with (budget, period) is supposed to have budget us in every period us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13432User:Pennpanda2014-12-19T16:55:49Z<p>Pennpanda: /* Introduction */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The Real-Time Deferrable Server (rtds) scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced with name '''rtds''' in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with (budget, period) is supposed to have budget us in every period us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13431User:Pennpanda2014-12-19T16:54:35Z<p>Pennpanda: /* Usage */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with (budget, period) is supposed to have budget us in every period us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget>us and period to <period>us of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13430User:Pennpanda2014-12-19T16:54:12Z<p>Pennpanda: /* Description */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a budget and a period. The VCPU with (budget, period) is supposed to have budget us in every period us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13429User:Pennpanda2014-12-19T16:53:30Z<p>Pennpanda: /* Algorithm */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' us in every '''period''' us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field to schedule these VCPUs. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible to a VCPU if the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13428User:Pennpanda2014-12-19T16:50:24Z<p>Pennpanda: /* Algorithm */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' us in every '''period''' us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority, where a VCPU's deadline in a period is equal to the end of the period. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13427User:Pennpanda2014-12-19T16:48:36Z<p>Pennpanda: /* Also See */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' us in every '''period''' us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descripting RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13426User:Pennpanda2014-12-19T16:48:25Z<p>Pennpanda: /* Also See */</p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' us in every '''period''' us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog descriping RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13425User:Pennpanda2014-12-19T16:47:53Z<p>Pennpanda: </p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' us in every '''period''' us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]<br />
*[https://sites.google.com/site/realtimexen/ RT-Xen website]<br />
*[https://blog.xenproject.org/2013/11/27/rt-xen-real-time-virtualization-in-xen/ Blog of RT-Xen]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13424User:Pennpanda2014-12-19T16:45:56Z<p>Pennpanda: </p>
<hr />
<div>==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' us in every '''period''' us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===<br />
*[http://xenbits.xen.org/docs/unstable/man/xl.1.html#scheduler_subcommands Scheduler Subcommands]</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13423User:Pennpanda2014-12-19T16:44:26Z<p>Pennpanda: </p>
<hr />
<div><br />
==Real-Time-Deferrable-Server-Based CPU Scheduler==<br />
===Introduction===<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
===Description===<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' us in every '''period''' us.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
===Usage===<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
===Algorithm===<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
===Glossary of Terms===<br />
*'''us''': microsecond<br />
*'''Host''': The physical hardware running Xen and hosting guest VMs.<br />
*'''VM''': Guest virtual machine.<br />
*'''VCPU''': Virtual CPU (one or more per VM).<br />
*'''CPU/PCPU''': Physical host CPU.<br />
*'''Period''': The period when a VCPU's budget is replenished or discarded.<br />
*'''Budget''': The amount of time a VCPU can execute within its period.<br />
<br />
===Also See===</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13422User:Pennpanda2014-12-19T16:38:10Z<p>Pennpanda: </p>
<hr />
<div>==RTDS Scheduler==<br />
===Real-Time-Deferrable-Server-Based CPU Scheduler===<br />
====Introduction====<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
====Description====<br />
Each VCPU of each domain is assigned a '''budget''' and a '''period'''. The VCPU with ('''budget''', '''period''') is supposed to have '''budget''' ms in every '''period''' ms.<br />
<br />
Note: The VCPUs of the same domain have the same parameters right now.<br />
<br />
====Usage====<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
====Algorithm====<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
====Glossary of Terms====<br />
<br />
====Also See====</div>Pennpandahttps://wiki.xenproject.org/index.php?title=User:Pennpanda&diff=13421User:Pennpanda2014-12-19T16:35:43Z<p>Pennpanda: Created page with "==RTDS Scheduler== ===Real-Time-Deferrable-Server-Based CPU Scheduler=== ====Introduction==== The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capa…"</p>
<hr />
<div>==RTDS Scheduler==<br />
===Real-Time-Deferrable-Server-Based CPU Scheduler===<br />
====Introduction====<br />
The rtds scheduler is a real-time CPU scheduler built to provide guaranteed CPU capacity to real-time workload on SMP hosts. It is introduced in Xen 4.5 as an experimental scheduler.<br />
<br />
====Description====<br />
<br />
<br />
<br />
====Usage====<br />
The "xl sched-rtds" command can be used to tune the per VM guest scheduler parameters.<br />
* '''xl sched-rtds -d <domain>''' :List the parameter of the specified <domain><br />
* '''xl sched-rtds -d <domain> -p <period> -b <budget>''' : Set each VCPU's budget to <budget> and period to <period> of the specified <domain><br />
<br />
====Algorithm====<br />
The design of this rtds scheduler is as follows:<br />
<br />
This scheduler follows the Preemptive Global Earliest Deadline First (EDF) theory in real-time field. At any scheduling point, the VCPU with earlier deadline has higher priority. The scheduler always picks the highest priority VCPU to run on a feasible PCPU. A PCPU is feasible if the VCPU can run on this PCPU and the PCPU is idle or has a lower-priority VCPU running on it.<br />
<br />
Each VCPU has a dedicated period and budget. The deadline of a VCPU is at the end of each period; A VCPU has its budget replenished at the beginning of each period; While scheduled, a VCPU burns its budget. The VCPU needs to finish its budget before its deadline in each period; The VCPU discards its unused budget at the end of each period. If a VCPU runs out of budget in a period, it has to wait until next period.<br />
<br />
Each VCPU is implemented as a deferable server. When a VCPU has a task running on it, its budget is continuously burned; When a VCPU has no task but with budget left, its budget is preserved.<br />
<br />
Queue scheme:<br />
A global runqueue and a global depletedq for each CPU pool. The runqueue holds all runnable VCPUs with budget and sorted by deadline; The depletedq holds all VCPUs without budget and unsorted.<br />
<br />
<br />
====Glossary of Terms====<br />
<br />
====Also See====</div>Pennpanda