linux-kernel - Re: RSDL v0.31

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1174119830.3144.22.camel@entropy>
Date:	Sat, 17 Mar 2007 01:23:50 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Mike Galbraith <efault@....de>, Con Kolivas <kernel@...ivas.org>,
	ck@....kolivas.org, Al Boldi <a1426z@...ab.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: RSDL v0.31

(sorry for the duplicate Ingo, this time I managed to Repy to All)

On Sat, 2007-03-17 at 08:45 +0100, Ingo Molnar wrote:
> * Nicholas Miell <nmiell@...cast.net> wrote:
> 
> > The X people have plans for how to go about fixing this, [...]
> 
> then we'll first have wait for those X changes to at least be done in a 
> minimal manner so that they can be tested for real with RSDL. (is it 
> _really_ due to that? Or will X regress forever once we switch to RSDL?)

Yes, it's an X problem.

There's two issues, really -- smooth pointer movement or the lack
thereof and the servicing of clients at varying priorities. There's
vague plans floating around about moving all input processing off into a
separate high-priority thread and pretty much no ideas how to deal with
mixed priority clients.

So, the current scheduler works around this brain damage using
heuristics that sort of do the job and sometimes screw things up.

> 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, simply 
> because it is a pretty negative effect that goes beyond any of the 
> visible positive improvements that RSDL brings over the current 
> scheduler. If it is better to fix X, then X has to be fixed _first_, at 
> least in form of a prototype patch that can be _tested_, and then the 
> result has to be validated against RSDL.
> 

RSDL is, above all else, fair. Predictably so.
Hacking around X's stupidity makes it no longer *be* RSDL.

Until they catch up to the early-90s technology-wise, we can just nice
-19 X.

-- 
Nicholas Miell <nmiell@...cast.net>

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