linux-kernel - Re: Ten percent test

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, 6 Apr 2007 12:03:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	Mike Galbraith <efault@....de>,
	linux list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ck list <ck@....kolivas.org>
Subject: Re: Ten percent test

* Con Kolivas <kernel@...ivas.org> wrote:

> > I was more focused on the general case, but all I should have to do 
> > to de-claw all of these sleep exploits is account rr time (only a 
> > couple of lines, done and building now).  It's only a couple of 
> > lines.
> 
> The more you try to "de-claw" these sleep exploits the less effective 
> you make your precious interactive estimator. Feel free to keep adding 
> endless tweaks to undo the other tweaks in order to try and achieve 
> what SD has by design.

firstly, testing on various workloads Mike's tweaks work pretty well, 
while SD still doesnt handle the high-load case all that well. Note that 
it was you who raised this whole issue to begin with: everything was 
pretty quiet in scheduling interactivity land. (There was one person who 
reported wide-scale interactivity regressions against mainline but he 
didnt answer my followup posts to trace/debug the scenario.)

SD has a built-in "interactivity estimator" as well, but hardcoded into 
its design. SD has its own set of ugly-looking tweaks as well - for 
example the prio_matrix. So it all comes down on 'what interactivity 
heuristics is enough', and which one is more tweakable. So far i've yet 
to see SD address the hackbench and make -j interactivity 
problems/regression for example, while Mike has been busy addressing the 
'exploits' reported against mainline.

> You'll end up with an incresingly complex state machine design of 
> interactivity tweaks and interactivity throttlers all fighting each 
> other to the point where the intearactivity estimator doesn't do 
> anything. [...]

It comes down to defining interactivity by scheduling behavior, and 
making that definition flexible. SD's definition of interactivity is 
rigid (but it's still behavior-based, so not fundamentally different 
from an explicit 'interactivity estimator'), and currently it does not 
work well under high load. But ... i'm still entertaining the notion 
that it might be good enough, but you've got to demonstrate the design's 
flexibility.

furthermore, your description does not match my experience when using 
Mike's tweaks and comparing it to SD on the same hardware. According to 
your claim i should have seen regressions popping up in various, 
already-fixed corners, but it didnt happen in practice. But ... i'm 
awaiting further SD and Mike tweaks, the race certainly looks 
interesting ;)

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