WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] scheduler rate controller

To: Dario Faggioli <raistlin@xxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] scheduler rate controller
From: George Dunlap <george.dunlap@xxxxxxxxxx>
Date: Fri, 28 Oct 2011 17:18:34 +0100
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir \(Xen.org\)" <keir@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Lv, Hui" <hui.lv@xxxxxxxxx>, "Duan, Jiangang" <jiangang.duan@xxxxxxxxx>
Delivery-date: Fri, 28 Oct 2011 09:12:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1319796584.19320.31.camel@Abyss>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@xxxxxxxxxxxxxx> <C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1319789425.19320.12.camel@Abyss> <C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1319796584.19320.31.camel@Abyss>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2011-10-28 at 11:09 +0100, Dario Faggioli wrote:
> Not sure yet, I can imagine it's tricky and I need to dig a bit more in
> the code, but I'll let know if I found a way of doing that...

There are lots of reasons why the SCHEDULE_SOFTIRQ gets raised.  But I
think we want to focus on the scheduler itself raising it as a result of
the .wake() callback.  Whether the .wake() happens as a result of a HW
interrupt or something else, I don't think really matters.

Dario and Hui,  neither of you have commented on my idea, which is
simply don't preempt a VM if it has run for less than some amount of
time (say, 500us or 1ms).  If a higher-priority VM is woken up, see how
long the current VM has run.  If it's less than 1ms, set a 1ms timer and
call schedule() then.

> > > More generally speaking, I see how this feature can be useful, and I
> > > also think it could live in the generic schedule.c code, but (as George
> > > was saying) the algorithm by which rate-limiting is happening needs to
> > > be well known, documented and exposed to the user (more than by means
> > > of a couple of perf-counters).
> > > 
> > 
> > One question is that, what is the right palace to document such 
> > information? I'd like to make it as clear as possible to the users.
> > 
> Well, don't know, maybe a WARN (a WARN_ONCE alike thing would probably
> be better), or in general something that leave a footstep in the logs,
> so that one can find out by means of `xl dmesg' or related. Obviously,
> I'm not suggesting of printk-ing each suppressed schedule invocation, or
> the overhead would get even worse... :-P
> 
> I'm thinking of something that happens the very first time the limiting
> fires, or maybe oncee some period/number of suppressions, just to remind
> the user that he's getting weird behaviour because _he_enabled_
> rate-limiting. Hopefully, that might also be useful for the user itself
> to fine tune the limiting parameters, although I think the perf-counters
> are already quite well suited for this.

As much as possible, we want the system to Just Work.  Under normal
circumstances it wouldn't be too unusual for a VM to have a several-ms
delay between receiving a physical interrupt and being scheduled; I
think that if the 1ms delay works, having it on all the time would
probably be the best solution.  That's another reason I'm in favor of
trying it -- it's simple and easy to understand, and doesn't require
detecting when to "turn it on".

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel