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: "Lv, Hui" <hui.lv@xxxxxxxxx>
Date: Fri, 28 Oct 2011 16:52:19 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "keir@xxxxxxx" <keir@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Duan, Jiangang" <jiangang.duan@xxxxxxxxx>
Delivery-date: Fri, 28 Oct 2011 01:53:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1319789425.19320.12.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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcyVSSsCrlfu7By1SaOUymK1pDDarQAA2Tgw
Thread-topic: [Xen-devel] [PATCH] scheduler rate controller
Thanks Dario for your helpful comments.

> Just something crossed my mind reading the patch and the comments,
> would it make sense to rate-limit the calls coming from (non-timer)
> interrupt exit paths while still letting the tick able to trigger a
> scheduling decision? This just to be sure that at least the time slice
> enforcing (if any) happens how expected... Could it make sense?
> 

Yes, it makes sense. But currently, we lacks the scheduler knowledge such as 
what caused the scheduler, timer or interrupt? Can we?

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

> For example this might completely destroy the time guarantees a
> scheduler  like sEDF would give, and in such case it must be easy
> enough to figure out what's going on and why the scheduler is not
> behaving as expected!
> 
> For that reason, although again, this could be made general enough to
> be sensible and meaningful for all the various schedulers, it might be
> worthwhile to have it inside credit1 for now, where we know it will
> probably yield the most of its benefits.
> 

I think I got your point. More considerations should be taken to avoid the 
disasters to any of the existing schedulers.
I'm fine to move it to the credit in the current stage. :)

> Just my 2 cents. :-)
> 
> Thanks and Regards,
> Dario
> 
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> ----------------------------------------------------------------------
> Dario Faggioli, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) PhD
> Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel