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]

Date:	Fri, 16 Mar 2007 23:44:17 -0800 (PST)
From:	David Lang <david.lang@...italinsight.com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Nicholas Miell <nmiell@...cast.net>,
	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

On Sat, 17 Mar 2007, 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?)
> 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.

why isn't niceing X to -10 an acceptable option?

if you overload the box enough things slow down, what scheduler avoids that?

where RSDL 'regresses' is with multiple CPU hog running at once (more then the 
number of real CPU's you have available) at the same priority, with one of them 
being the X server process.

the initial report was that with X + 2 cpu hogs on 1.5 cpu's there's more of a 
slowdown (even with a nice difference of 5 between X and the other processes)

the latest report is that with X and 11 cpu hogs and a nice difference of 10 
things slow down (I don't remember the number of cpu's from this report)

how much of an overload should the scheduler adjust for? a load of 3xcpu's? 
10x cpu's? what would be deemed acceptable?

if the key factor in a scheduler is to be able to run multiple CPU hogs at the 
same time as the X process, why not just check the name of the process running, 
and if it's X give it a nice boost?

while that would be easy to abuse, it would at least be predictable.

if the nice levels don't have enough of an effect, how much of an effect should 
a given nice level have? (con has asked this several times, I haven't seen an 
answer from anyone)

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