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: <1462694935.4155.83.camel@suse.de>
Date:	Sun, 08 May 2016 10:08:55 +0200
From:	Mike Galbraith <mgalbraith@...e.de>
To:	Yuyang Du <yuyang.du@...el.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Chris Mason <clm@...com>,
	Ingo Molnar <mingo@...nel.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: sched: tweak select_idle_sibling to look for idle threads

On Sat, 2016-05-07 at 09:24 +0800, Yuyang Du wrote:
> On Sun, May 01, 2016 at 11:20:25AM +0200, Mike Galbraith wrote:

> > Playing with Chris' benchmark, seems the biggest problem is that we
> > don't buddy up waker of many and it's wakees in a node.. ie the wake
> > wide thing isn't necessarily our friend when there are multiple wakers
> > of many.  If I run an instance per node with one mother of all work in
> > autobench mode, it works exactly as you'd expect, game over is when
> > wakees = socket size. It never get's near that point if I let things
> > wander, it beats itself up well before we get there.
> 
> Maybe give the criteria a bit margin, not just wakees tend to equal llc_size,
> but the numbers are so wild to easily break the fragile condition, like:

Seems lockless traversal and averages just lets multiple CPUs select
the same spot.  An atomic reservation (feature) when looking for an
idle spot (also for fork) might fix it up.  Run the thing as RT,
push/pull ensures that it reaches box saturation regardless of the
number of messaging threads, whereas with fair class, any number > 1
will certainly stack tasks before the box is saturated.

	-Mike

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ