RE: [PATCH] scheduler rate controller

[Dario Faggioli <raistlin@linux.it>]

[-- Attachment #1.1: Type: text/plain, Size: 3147 bytes --]

On Fri, 2011-10-28 at 17:18 +0100, George Dunlap wrote:
> 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.
> 
I fully agree, since these are the events that are likely to cause a
context switch, and it's the context switch that --when happening too
frequently-- trashes the performances, isn't it?

> 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.
> 
Right, I was about to, but the got busy with other stuff. To me, it
sounds a more than valid method for achieving similar results. Maybe I
like it more than pure rate-limiting because it makes it easier to
understand what's going on, especially from the final user point of
view, and thus also easier to configure and to be dealt with.

However, the  effect is still pretty much the same, and this is also
able to cause "scheduling artifact", and affect guarantees and/or
expected behaviour, e.g., in EDF, if the earliest deadline task wakes up
right after a context switch it would need to run, independently on for
how long current is running, and not doing so could jeopardize
schedulability. 

Again, I'm not saying something like that shouldn't be done at all, just
that --if it is something special kicking in from time to time-- it
should make itsself evident.

> 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".
> 
Ok, that's the other way around. Having it all the time is pretty much
self evident so, if we're fine with the latency this introduces, and it
improves fairness and performances , this could be the way. From my
experience in real-time scheduling, ms alike scheduling latency is
something very very huge... But this obviously depend on the workload.

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)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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