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:	Tue, 10 Apr 2007 14:04:49 +0200
From:	Mike Galbraith <efault@....de>
To:	Ed Tomlinson <edt@....ca>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Con Kolivas <kernel@...ivas.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ck list <ck@....kolivas.org>
Subject: Re: Ten percent test

On Tue, 2007-04-10 at 07:23 -0400, Ed Tomlinson wrote:
> On Monday 09 April 2007 22:39, Mike Galbraith wrote:
> > On Mon, 2007-04-09 at 07:38 +0200, Mike Galbraith wrote:
> > 
> > > I don't think you can have very much effect on latency using nice with
> > > SD once the CPU is fully utilized.  See below.
> > > 
> > > /*
> > >  * This contains a bitmap for each dynamic priority level with empty slots
> > >  * for the valid priorities each different nice level can have. It allows
> > >  * us to stagger the slots where differing priorities run in a way that
> > >  * keeps latency differences between different nice levels at a minimum.
> > >  * ie, where 0 means a slot for that priority, priority running from left to
> > >  * right:
> > >  * nice -20 0000000000000000000000000000000000000000
> > >  * nice -10 1001000100100010001001000100010010001000
> > >  * nice   0 0101010101010101010101010101010101010101
> > >  * nice   5 1101011010110101101011010110101101011011
> > >  * nice  10 0110111011011101110110111011101101110111
> > >  * nice  15 0111110111111011111101111101111110111111
> > >  * nice  19 1111111111111111111011111111111111111111
> > >  */
> > > 
> > > Nice allocates bandwidth, but as long as the CPU is busy, tasks always
> > > proceed downward in priority until they hit the expired array.  That's
> > > the design.
> > 
> > There's another aspect of this that may require some thought - kernel
> > threads.  As load increases, so does rotation length.  Would you really
> > want CPU hogs routinely preempting house-keepers under load?
> 
> SD has a schedule batch nice level.  This is good for tasks that want lots
> of cpu when they can get it.  If you overload your cpu I expect the box
> to slow down - including kernel threads.  If really required they can be
> started with a higher priority...

Sure.  Anything that is latency sensitive, and those kernel threads that
are necessary for system function can be made RT to bypass the designed
in latency.  It's just another thing that should be considered before
integration.  Now if burst loads (only one of which it the desktop)
would just cease to exist...

	-Mike

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