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

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



>>> On 19.12.11 at 14:59, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Mon, Dec 19, 2011 at 12:05 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> The way it stands now, the ratelimit value will override the timeslice
>>> value.  It had to be one way or the other; do you think the timeslice
>>> value should be the priority?
>>
>> The minimum of both should be used, I would think.
> 
> What do you mean?  You mean in the assignment above?

Yes, I had thought that this would suffice. But ...

> That won't have any effect other than increasing interrupts and trips
> through the scheduler.  Suppose the following set of events:
> * timeslice is set to 1ms, ratelimit_us to 5000.
> * a vcpu V is chosen; it's set to run with 1ms timeout.
> * 1ms later, we go through the scheduler; the ratelimit code
> determines that it hasn't run for long enough (only 1ms), so choses it
> to run again (with a 1ms timeslice)
> * Repeat until V has run for 5ms.

... if that's what's happening, the whole thing looks bogus to me.
Clearly the rate limit code should not force the time slice to be
extended.

> So although the timeslice is set to 1ms, and interrupts are happening
> after 1ms, the ratelimit is overriding the 1ms of the timeslice and
> making it 5ms.  Fundamentally, one of the two parameters must override
> the other.  With this patch the way it is now, ratelimit will override
> timeslice.  if you want the timeslice to override ratelimit, then
> there will have to be more code to make that happen.

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


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


 


Rackspace

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