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]

Message-Id: <200704061928.39155.kernel@kolivas.org>
Date:	Fri, 6 Apr 2007 19:28:38 +1000
From:	Con Kolivas <kernel@...ivas.org>
To:	Mike Galbraith <efault@....de>
Cc:	Ingo Molnar <mingo@...e.hu>,
	linux list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ck list <ck@....kolivas.org>
Subject: Re: Ten percent test

On Friday 06 April 2007 19:07, Mike Galbraith wrote:
> On Fri, 2007-04-06 at 11:03 +1000, Con Kolivas wrote:
> > On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
> > >  - fiftyp.c:  noticeable, but alot better than previously!
> >
> > fiftyp.c seems to have been stumbled across by accident as having an
> > effect when Xenofon was trying to recreate Mike's 50% x 3 test case. I
> > suggest a ten percent version like the following would be more useful as
> > a test for the harmful effect discovered in fiftyp.c. (/me throws in
> > obligatory code style change).
> >
> > Starts 15 processes that sleep ten times longer than they run. Change
> > forks to 15 times the number of cpus you have and it should work on any
> > size hardware.
>
> 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. 
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. What's the 
point in that? Eventually you'll have an estimator throttled to the point it 
does nothing and you end up with something far less interactive than SD which 
is as interactive as fairness allows, unlike mainline.

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