From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] xen/sched_credit: Use delay to control scheduling frequency Date: Tue, 20 Dec 2011 10:26:42 +0000 Message-ID: <1324376802.2143.154.camel@elijah> References: <114495d1ff947737518b.1324332781@wsm-ep-n0> <1324372056.23729.8.camel@zakaz.uk.xensource.com> <1324375765.6616.9.camel@Abyss> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1324375765.6616.9.camel@Abyss> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dario Faggioli Cc: George Dunlap , "xen-devel@lists.xensource.com" , Ian Campbell , Jan Beulich , "Lv, Hui" List-Id: xen-devel@lists.xenproject.org On Tue, 2011-12-20 at 10:09 +0000, Dario Faggioli wrote: > On Tue, 2011-12-20 at 17:44 +0800, Lv, Hui wrote: > > > It that constraint enforced anywhere? > > > > Currently, it's not constraint enforced. > > I think George have gave the explanation in yesterday's discussion. > > > I think that too, but maybe you can print some kind of warning when it > happens? I guess the consensus is that we should put in some effort to make the interface more polished. How about this: First, add a ratelimit_us element to csched_priv, just like the current tslice_ms element. When the scheduler comes up (in csched_init), it checks to see if MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tslice_ms); if so, it prints a warning, and sets prv->ratelimit_us to 1000*prv->tslice_ms. In the future, when we implement the domctls to change a scheduler's ratelimit_us, and tslice_ms, we disallow changes which would violate the "ratelimit < tslice" rule (returning -EINVAL or something like that). Thoughts? -George