From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v2] xen/credit scheduler; Use delay to control scheduling frequency Date: Mon, 19 Dec 2011 17:04:16 +0000 Message-ID: <4EEF7CA00200007800068E3D@nat28.tlf.novell.com> References: <4EEF02E20200007800068C60@nat28.tlf.novell.com> <4EEF36A60200007800068D43@nat28.tlf.novell.com> <4EEF5F720200007800068DB3@nat28.tlf.novell.com> <4EEF686E0200007800068DCC@nat28.tlf.novell.com> <1324313328.2143.74.camel@elijah> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1324313328.2143.74.camel@elijah> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap , George.Dunlap@eu.citrix.com Cc: Kevin Tian , "xen-devel@lists.xensource.com" , "Keir(Xen.org)" , Eddie Dong , Hui Lv , Jiangang Duan , Zhidong Yu List-Id: xen-devel@lists.xenproject.org >>> On 19.12.11 at 17:48, George Dunlap wrote: > 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. Oh, okay, I missed that point. In that case just warning about the two values having a bad relation would seem fine. Sorry for the noise then. Jan