lkml.org 
[lkml]   [2010]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: Ideal Adaptive Spinning Conditions
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?

--
error compiling committee.c: too many arguments to function



\
 
 \ /
  Last update: 2010-04-01 18:41    [W:0.190 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site