Message-Id: <200703172048.46267.kernel@kolivas.org>
Date:	Sat, 17 Mar 2007 20:48:45 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	ck@....kolivas.org
Cc:	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	Ingo Molnar <mingo@...e.hu>, Al Boldi <a1426z@...ab.com>,
	Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org,
	Nicholas Miell <nmiell@...cast.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: RSDL v0.31

On Saturday 17 March 2007 19:41, Serge Belyshev wrote:
> Ingo Molnar <mingo@...e.hu> writes:
> > * Nicholas Miell <nmiell@...cast.net> wrote:
> >> The X people have plans for how to go about fixing this, [...]
> >
> > [...] Or will X regress forever once we switch to RSDL?)
> > We cannot regress the scheduling of a workload as important as "X mixed
> > with CPU-intense tasks". And "in theory this should be fixed if X is
> > fixed" does not cut it. X is pretty much _the_ most important thing to
> > optimize the interactive behavior of a Linux scheduler for. Also,
> > paradoxically, it is precisely the improvement of _X_ workloads that
> > RSDL argues with.
> >
> > this regression has to be fixed before RSDL can be merged, [...]
>
> Let me restate the fact, if it wasn't obvious enough, that most people
> who tried RSDL (and most of them use desktop systems, me including) never
> see any regressions compared to mainline. Quite contrary -- their
> impressions were that with RSDL desktop system runs more smoothly, even
> under fierce load, which was never possible with mainline scheduler.
>
> (see http://article.gmane.org/gmane.linux.kernel/504068 for a list
> of references.)

Well despite being in a drug induced stupor I find I have to reply on this 
thread. Hopefully I'm not doing my code a disservice by doing so. Who knows, 
maybe I make more sense?

The most frustrating part of a discussion of this nature on lkml is that 
earlier information in a thread seems to be long forgotten after a few days 
and all that is left is the one reporter having a problem. That's not to deny 
the one user is having a problem, but when you have a thousand downloads (no 
exaggeration) and only one person remains reporting badness it's frustrating 
that the problem actually comes down to one of semantics rather than a bug 
(will I nice or won't I).

So in an attempt to summarise the situation, what are the advantages of RSDL 
over mainline.

Fairness
Starvation free
Much lower and bound latencies
Deterministic
Better interactivity for the majority of cases.

Now concentrating on the very last aspect since that seems to be the sticking 
point.

I won't try and estimate what percentage is better, but overall it is _far_ 
more, _not_ less. The few scenarios that mainline remains better are 
unpredictable. This is where it gets interesting, because unlike mainline 
which does not have a good solution for the rest of the problems, all it 
takes is to renice X and then you have RSDL outperforming virtually always.

As for SCHED_BATCH on mainline, I think you'll find it is NOT as deterministic 
as you believe, leads to woeful interactivity, and still is starveable (just 
sleep just before your timeslice runs out). That is not a valid solution I'm 
sorry to say.

Despite the claims to the contrary, RSDL does not have _less_ heuristics, it 
does not have _any_. It's purely entitlement based. 

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