Measurements done by Intel on the SpecVirt benchmark found out that there may be up to 15,000 schedules per second. There may be cases where interrupt intensive workloads (i.e., an interrupt wakes up a VM, which does a few microseconds work, and goes back to sleep), coupled with the boosting of vCPUs doing I/O enacted by Credit, causes thousands of scheduler invocation per second. Therefore, using a different (smaller?) timeslice value may be potentially beneficial for a particular workflow, but that can only be assessed by experimentations. There has been an attempt to change it to something smaller, but, unfortunately, because of the intrinsic characteristics of the Credit algorithm, changing timeslice has some not easily predictable side effects, so the change was pushed back. The default value of 30ms is universally recognised as being anachronistically too high. Possible good values may be 10ms, 5ms, and 1ms, with smaller values allegedly being better suited for latency-sensitive workloads, but at the cost of increased the overhead from context, and reduced CPU cache effectiveness. This can be set either using the Xen command-line option, sched_credit_tslice_ms, or, at run time, with xl sched-credit: In Xen 4.2, we introduced the tslice_ms scheduler parameter. Credit has, by default, a timeslice of 30ms, which can be considered a faiirly long. The best timeslice value, though, is highly workload dependant. And if yes, some other vCPU is put into execution.Ī long timeslice is usually good for achieving high throughput of CPU intensive workloads, as it prevents context switches to happen too frequently, which may lead to trashing of CPU and cache(s). Timeslice (also known, in other contexts, as scheduling quantum) is for how long a vCPU can run before the scheduler itself chimes in, and if a preemption should occur. In case applications in need of low latancies (some class of networking applications, audio, etc.) suffers, a potential mitigation would be to change the timeslice (see below). It is providing satisfactory performance, for a lot of workloads. Roughly speaking, this means that vCPUs that wakes up after having been waiting for I/O, will likely get to run immediately.Ĭredit is the default scheduler of Xen.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |