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

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

On Mon, 2011-12-19 at 15:38 +0000, Jan Beulich wrote:
> >>> On 19.12.11 at 16:25, "Lv, Hui" <hui.lv@intel.com> 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.

It would make sense, in theory, to let the VM run for the rest of its
timeslice; but there's not an easy way at the moment to get that
information from an already-running vcpu.  The timescales we're talking
about here are so small that it doesn't seem worth the extra
complication to me.

We're really bike-shedding at this point.  I don't think
functionality-wise it matters either way, and the code is simpler the
way it is.  I think we should just leave it.

 -George