[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 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.

Jan

> If, this unfortunately happens, I prefer to put "rate_limit" at higher 
> priority, which means extending the running time slice.
> Some warnings should be put before the parameter of sched_ratelimit_us to 
> avoid this.
> Is this reasonable?




_______________________________________________
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®.