lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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