Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
From: David Lang
Date: Mon Mar 12 2007 - 20:07:30 EST
On Mon, 12 Mar 2007, Mike Galbraith wrote:
On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
Killing the known corner case starvation scenarios is wonderful, but
let's not just pretend that interactive tasks don't have any special
requirements.
Now you're really making a stretch of things. Where on earth did I say that
interactive tasks don't have special requirements? It's a fundamental feature
of this scheduler that I go to great pains to get them as low latency as
possible and their fair share of cpu despite having a completely fair cpu
distribution.
As soon as your cpu is fully utilized, fairness looses or interactivity
loses. Pick one.
correct.
the problem is that it's hard (if not impossible) to properly identify what is
needed to make a system have good interactivity. in some cases it's a matter of
low latency (wake up a process as quickly as you can when whatever it was
waiting on is available), but in others it's a matter of allocating the _right_
process enough CPU (X needs enough CPU to do things)
where it's a matter of needing low-latency, it's possible to design a scheduler
that will do things in a predictable enough way that you know the max latency
you have to deal with (and the RSDL seems to do this)
the problem comes when this isn't enough. if you have several CPU hogs on a
system, and they are all around the same priority level, how can the scheduler
know which one needs the CPU the most for good interactivity?
in some cases you may be able to directly detect that your high-priority process
is waiting for another one (tracing pipes and local sockets for example), but
what if you are waiting for several of them? (think a multimedia desktop waiting
for the sound card, CDRom, hard drive, and video all at once) which one needs
the extra CPU the most?
Fairness is much easier to enforce (and much easier to understand)
the RSDL is concentrating on enforcing fairness, with bounded (and predictable)
latencies.
if you are willing to tell the system what you consider more important (and how
much more important you consider it), then it's much easier to figure out who to
give the CPU to. Con is just asking you to do this (and you already do, by doing
a nice -5. but it sounds like you want that to mean more then it currently does)
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/