[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1173692286.20540.12.camel@Homer.simpson.net>
Date: Mon, 12 Mar 2007 10:38:06 +0100
From: Mike Galbraith <efault@....de>
To: Con Kolivas <kernel@...ivas.org>
Cc: Ingo Molnar <mingo@...e.hu>,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
ck list <ck@....kolivas.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > I'll save you the trouble. I just checked myself and indeed the load is
> > > only 1. What this means is that although there are 2 tasks running, only
> > > one is running at any time making a total load of 1. So, if we add two
> > > other tasks that add 2 more to the load the total load is 3. However if
> > > we weight the other two tasks at nice 5, they only add .75 each to the
> > > load making a weighted total of 2.5. This means that X+Gforce together
> > > should get a total of 1/2.5 or 40% of the overall cpu. That sounds like
> > > exactly what you're describing is happening.
> >
> > Hmm. So... anything that's client/server is going to suffer horribly
> > unless niced tasks are niced all the way down to 19?
>
> Fortunately most client server models dont usually have mutually exclusive cpu
> use like this X case. There are many things about X that are still a little
> (/me tries to think of a relatively neutral term)... wanting. :(
But the reality of X is what we have to deal with.
This scheduler seems to close the corner cases of the interactivity
estimator, but this "any background load is palpable" thing is decidedly
detrimental to interactive feel.
When I looked into keeping interactive tasks responsive, I came to the
conclusion that I just couldn't get there from here across the full
spectrum of cpu usage without a scheduler hint. Interactive feel is
absolutely dependent upon unfairness in many cases, and targeting that
unfairness gets it right where heuristics sometimes can't.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists