[lkml]   [2007]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
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?

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

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

Anyway for my next trick I plan to make -nice values not suck again. So we can
go full circle and start renicing X (only if you so desire) as well like we
used to. I figure that's the only way left to satisfy all requirements to
beat even those last 5%. However for the most part I don't even think
renicing X will be required (and hasn't been prior to this testcase).
Nonetheless unsucking negative nice values is probably worthwhile.

I need time to make it so though. Precious sleep and mood has been destroyed
this week.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-03-12 19:53    [W:0.142 / U:2.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site