From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2] xen/credit scheduler; Use delay to control scheduling frequency Date: Mon, 19 Dec 2011 16:48:48 +0000 Message-ID: <1324313328.2143.74.camel@elijah> References: <4EEF02E20200007800068C60@nat28.tlf.novell.com> <4EEF36A60200007800068D43@nat28.tlf.novell.com> <4EEF5F720200007800068DB3@nat28.tlf.novell.com> <4EEF686E0200007800068DCC@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EEF686E0200007800068DCC@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Kevin Tian , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , George Dunlap , Eddie Dong , Hui Lv , Jiangang Duan , Zhidong Yu List-Id: xen-devel@lists.xenproject.org On Mon, 2011-12-19 at 15:38 +0000, Jan Beulich wrote: > >>> On 19.12.11 at 16:25, "Lv, Hui" 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