[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |