[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] credit: Change default timeslice to 5ms

On 03/05/2014 05:18 PM, David Vrabel wrote:
On 05/03/14 16:29, George Dunlap wrote:
The 30ms timeslice was chosen nearly a decade ago now, with cpu
"burning" workloads in mind.  In the mean time, processors have gotten
faster and VMEXITs have gotten faster.  A timeslice of 30ms has a
major cost when running latency-sensitive workloads like network or
audio streaming: getting caught behind just one or two other VMs can
introduce a processing delay of up to 60ms, and the "round-robin"
nature of the credit scheduler means this delay may be introduced
every time the VM yields for periods of time.

The XenServer performance team at Citrix have done extensive testing
with various timeslices, including 30ms, 10ms, 5ms, and 2ms.  None of
the workloads exhibited any performance degradation with a 5ms
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -29,9 +29,9 @@
   * Basic constants
  #define CSCHED_DEFAULT_WEIGHT       256
-/* Default timeslice: 30ms */
The TICKS_PER_TSLICE change doubles the tick rate.  Is this intentional?
  It's not mentioned in the commit message.

Hmm -- actually, I just realized that Marcus' test was done with 3 ticks per timeslice, so "5ms / 1 tick" has *not* been validated. And this is actually important, because the main purpose of the ticks is to give the scheduler an opportunity to switch VMs out of "BOOST" priority and into "UNDER" priority. Reducing the ticks per timeslice changes that dynamic, and would need to be tested separately.

Also, I just discovered a rather pathological case in general that seems to be in the scheduler, so for the time being let me retract this while I figure that out.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.