Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 01 Apr 2010 19:10:14 +0300 | From | Avi Kivity <> | Subject | Re: 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
| ![\](/images/icornerr.gif) |