On Friday 07 April 2006 23:37, Mike Galbraith wrote:
> On Fri, 2006-04-07 at 22:56 +1000, Con Kolivas wrote:
> > This mechanism is designed to convert on-runqueue waiting time into
> > sleep. The basic reason is that when the system is loaded, every task is
> > fighting for cpu even if they only want say 1% cpu which means they never
> > sleep and are waiting on a runqueue instead of sleeping 99% of the time.
> > What you're doing is exactly biasing against what this mechanism is in
> > place for. You'll get the same effect by bypassing or removing it
> > entirely. Should we do that instead?
>
> Heck no. That mechanism is just as much about fairness as it is about
> intertactivity, and as such is just fine and dandy in my book... once
> it's toned down a bit^H^H^Htruckload. What I'm doing isn't biasing
> against the intent, I'm merely straightening the huge bend in favor of
> interactive tasks who get this added boost over and over again, and
> restricting the general effect to something practical.
Have you actually tried without that mechanism? No compromise will be correct
there for fairness one way or the other. There simply is no way to tell if a
task is really sleeping or really just waiting on a runqueue. That's why Ingo
weighted the tasks waking from interrupts more because of their likely
intent. It's still a best guess scenario (which I'm sure you know). Wouldn't
it be lovely to have a system that didn't guess and had simple sleep/wake cpu
usage based heuristics? Oh well.
> Just look at what that mechanism does now with a 10 deep queue. Every
> dinky sleep can have an absolutely huge gob added to it, the exact worst
> case number depends on how many cpus you have and whatnot. Start a slew
> of tasks, and you are doomed to have every task that sleeps for the
> tiniest bit pegged at max interactive.
I'm quite aware of the effect it has :)
> Maybe what I did isn't the best that can be done, but something has to
> be done about that. It is very b0rken under heavy load.
Your compromise is as good as any.
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
