Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Mike Galbraith]

On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > Mike the cpu is being proportioned out perfectly according to fairness as
> > > I mentioned in the prior email, yet X is getting the lower latency
> > > scheduling. I'm not sure within the bounds of fairness what more would
> > > you have happen to your liking with this test case?
> >
> > It has been said that "perfection is the enemy of good".  The two
> > interactive tasks receiving 40% cpu while two niced background jobs
> > receive 60% may well be perfect, but it's damn sure not good.
> 
> Again I think your test is not a valid testcase. Why use two threads for your 
> encoding with one cpu? Is that what other dedicated desktop OSs would do?

The testcase is perfectly valid.  My buddies box has two full cores, so
we used two encoders such that whatever bandwidth is not being actively
consumed by more important things gets translated into mp3 encoding.

How would you go about ensuring that there won't be any cycles wasted?
 
_My_ box has 1 core that if fully utilized translates to 1.2 cores.. or
whatever, depending on the phase of the moon.  But no matter, logical vs
physical cpu argument is pure hand-waving.  What really matters here is
the bottom line: your fair scheduler ignores the very real requirements
of interactivity.

> And let's not lose sight of things with this one testcase.
> 
> RSDL fixes
> - every starvation case
> - all fairness isssues
> - is better 95% of the time on the desktop

I don't know where you got that 95% number from.  For the most part, the
existing scheduler does well.  If it sucked 95% of the time, it would
have been shredded a long time ago.

> If we fix 95% of the desktop and worsen 5% is that bad given how much else 
> we've gained in the process?

Killing the known corner case starvation scenarios is wonderful, but
let's not just pretend that interactive tasks don't have any special
requirements.

	-Mike

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