Re: RFC: Ideal Adaptive Spinning Conditions

[Avi Kivity]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/