linux-kernel - Re: RFC: Ideal Adaptive Spinning Conditions

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:	Thu, 01 Apr 2010 20:15:13 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Darren Hart <dvhltc@...ibm.com>
CC:	"lkml, " <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Sven-Thorsten Dietrich <sdietrich@...ell.com>,
	Peter Morreale <pmorreale@...ell.com>,
	Chris Wright <chrisw@...s-sol.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Chris Mason <chris.mason@...cle.com>
Subject: Re: RFC: Ideal Adaptive Spinning Conditions

On 04/01/2010 08:10 PM, Darren Hart wrote:
> Avi Kivity wrote:
>> On 04/01/2010 06:54 PM, Darren Hart wrote:
>>>> A lock(); unlock(); loop spends most of its time with the lock held 
>>>> or contended.  Can you something like this:
>>>>
>>>>
>>>>    lock();
>>>>    for (i = 0; i < 1000; ++i)
>>>>         asm volatile ("" : : : "memory");
>>>>    unlock();
>>>>    for (i = 0; i < 10000; ++i)
>>>>         asm volatile ("" : : : "memory");
>>>
>>>
>>>
>>> Great idea. I'll be doing a more rigorous investigation on this of 
>>> course, but I thought I'd share the results of just dumping this 
>>> into the testcase:
>>>
>>> # ./futex_lock -i10000000
>>> futex_lock: Measure FUTEX_LOCK operations per second
>>>     Arguments: iterations=10000000 threads=256 adaptive=0
>>> Result: 420 Kiter/s
>>> lock calls:      9999872
>>> lock syscalls:   665824 (6.66%)
>>> unlock calls:    9999872
>>> unlock syscalls: 861240 (8.61%)
>>>
>>> # ./futex_lock -a -i10000000
>>> futex_lock: Measure FUTEX_LOCK operations per second
>>>     Arguments: iterations=10000000 threads=256 adaptive=1
>>> Result: 426 Kiter/s
>>> lock calls:      9999872
>>> lock syscalls:   558787 (5.59%)
>>> unlock calls:    9999872
>>> unlock syscalls: 603412 (6.03%)
>>>
>>> This is the first time I've seen adaptive locking have an advantage! 
>>> The second set of runs showed a slightly greater advantage. Note 
>>> that this was still with spinners being limited to one.
>>
>> Question - do all threads finish at the same time, or wildly 
>> different times?
>
> I'm not sure, I can add some fairness metrics to the test that will 
> help characterize how that's working. My suspicion is that there will 
> be several threads that don't make any progress until the very end - 
> since adaptive spinning is an "unfair" locking technique.
>

Well, if the amount of unfairness differs between the tests (unfair 
unfairness?) then you may see results that are not directly related to 
spin vs yield.  You need to make the test more self-regulating so the 
results are more repeatable (yet not make it a round-robin test).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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