linux-kernel - Re: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex

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: <alpine.DEB.2.10.1407212330090.20847@nanos>
Date:	Mon, 21 Jul 2014 23:41:05 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ingo Molnar <mingo@...nel.org>
cc:	Waiman Long <Waiman.Long@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	Darren Hart <dvhart@...ux.intel.com>,
	Davidlohr Bueso <davidlohr@...com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
	linux-doc@...r.kernel.org, Jason Low <jason.low2@...com>,
	Scott J Norton <scott.norton@...com>
Subject: Re: [RFC PATCH 0/5] futex: introduce an optimistic spinning futex

On Mon, 21 Jul 2014, Ingo Molnar wrote:
> * Waiman Long <Waiman.Long@...com> wrote:
> 
> > Testing done on a 4-socket Westmere-EX boxes with 40 cores (HT off) 
> > showed the following performance data (average kops/s) with various 
> > load factor (number of pause instructions) used in the critical 
> > section using an userspace mutex microbenchmark.
> > 
> >   Threads  Load	Waiting Futex	Spinning Futex 	  %Change
> >   -------  ----	-------------	--------------	  -------
> >     256	     1	     6894	    8883	    +29%
> >     256	    10	     3656	    4912	    +34%
> >     256	    50	     1332	    4358	   +227%
> >     256	   100	      792	    2753	   +248%
> >      10	     1	     6382	    4838	    -24%
> >      10	    10	     3614	    4748	    +31%
> >      10	    50	     1319	    3900	   +196%
> >      10	   100	      782	    2459	   +214%
> >       2	     1	     7905	    7194	   -9.0%
> >       2	    10	     4556	    4717	   +3.5%
> >       2	    50	     2191	    4167	    +90%
> >       2	   100	     1767	    2407	    +36%
> 
> So the numbers look interesting - but it would be _really_ important 
> to provide noise/sttdev figures in a sixth column as well (denoted in 
> percentage units, not in benchmark units), so that we know how 
> significant a particular speedup (or slowdown) is.

We care about that, once we have something which

 - Has a proper design

 - Covers all the corner cases of futexes

 - Does not introduce a gazillions of new lines of codes in futex.c

 - Does not create another set of subtle security issues. I'm so not
   interested to do the same exercise again - my brain still suffers.

The numbers provided are completely irrelevant as the implementation
is just the most idiotic approach to avoid all corner cases of
futexes, error handling and the proper treatment of detached kernel
state for the price of adding a completely unreviewable clusterfuck to
futex.c.

So, no. Don't encourage that number wankery any further. It's going
nowhere, period.

Thanks,

	tglx


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