lkml.org 
[lkml]   [2007]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RSDL v0.31
Date
On Saturday 17 March 2007 19:41, Serge Belyshev wrote:
> Ingo Molnar <mingo@elte.hu> writes:
> > * Nicholas Miell <nmiell@comcast.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-03-17 10:51    [W:0.148 / U:6.484 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site