Re: [Xen-devel] [PATCH v2] xen/credit scheduler; Use delay to control scheduling frequency

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.12.11 at 17:48, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> On Mon, 2011-12-19 at 15:38 +0000, Jan Beulich wrote:
>> >>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@xxxxxxxxx> wrote:
>> >> Overriding the rate limit by the time slice isn't the right thing either, 
> as 
>> > that
>> >> (the way I "read" it) means there's no rate limiting at all.
>> >> What "rate limit" to me means is preventing quickly switching away from a
>> >> vCPU recently scheduled without extending its (remaining) time slice, 
>> >> i.e. 
>> > in any
>> >> place a respective evaluation is done the shorter of the two should be 
> used.
>> >> 
>> >> Jan
>> > 
>> > So the basic thing is to avoid "time slice" < "rate limit", happen.
>> > I really don't understand why people want a 1ms time slice, but set the 
>> > rate_limit to 5000(us), that is insubstantial.
>> 
>> So if someone set the (global) rate limit value to 5000us and then,
>> days or weeks later, migrates a VM with a 3ms time slice to that
>> host, why should this be an admin mistake? To me, the rate limit is a
>> performance improvement, while the time slice may be (an indirect
>> result of) a to be enforced policy.
> 
> Right now the timeslice is effectively global.  There's a per-scheduler
> variable, but it's only set from the boot-time option.  Before 4.2 I'm
> going to add some code that will allow that to be changed on a scheduler
> granularity; but there was never a plan to make it per-VM.

Oh, okay, I missed that point. In that case just warning about the
two values having a bad relation would seem fine.

Sorry for the noise then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel