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

[George Dunlap <george.dunlap@eu.citrix.com>]

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
>> timeslice.
> [...]
>> --- a/xen/common/sched_credit.c
>> +++ b/xen/common/sched_credit.c
>> @@ -29,9 +29,9 @@
>>    * Basic constants
>>    */
>>   #define CSCHED_DEFAULT_WEIGHT       256
>> -#define CSCHED_TICKS_PER_TSLICE     3
>> -/* Default timeslice: 30ms */
>> -#define CSCHED_DEFAULT_TSLICE_MS    30
>> +#define CSCHED_TICKS_PER_TSLICE     1
> 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.

  -George