Re: RFC: Ideal Adaptive Spinning Conditions

From: Avi Kivity
Date: Thu Apr 01 2010 - 12:31:24 EST

On 04/01/2010 02:21 AM, Darren Hart wrote:
I'm looking at some adaptive spinning with futexes as a way to help reduce the dependence on sched_yield() to implement userspace spinlocks. Chris, I included you in the CC after reading your comments regarding sched_yield() at kernel summit and I thought you might be interested.

I have an experimental patchset that implements FUTEX_LOCK and FUTEX_LOCK_ADAPTIVE in the kernel and use something akin to mutex_spin_on_owner() for the first waiter to spin. What I'm finding is that adaptive spinning actually hurts my particular test case, so I was hoping to poll people for context regarding the existing adaptive spinning implementations in the kernel as to where we see benefit. Under which conditions does adaptive spinning help?

I presume locks with a short average hold time stand to gain the most as the longer the lock is held the more likely the spinner will expire its timeslice or that the scheduling gain becomes noise in the acquisition time. My test case simple calls "lock();unlock()" for a fixed number of iterations and reports the iterations per second at the end of the run. It can run with an arbitrary number of threads as well. I typically run with 256 threads for 10M iterations.

futex_lock: Result: 635 Kiter/s
futex_lock_adaptive: Result: 542 Kiter/s

A lock(); unlock(); loop spends most of its time with the lock held or contended. Can you something like this:

for (i = 0; i < 1000; ++i)
asm volatile ("" : : : "memory");
for (i = 0; i < 10000; ++i)
asm volatile ("" : : : "memory");

This simulates a lock hold ratio of 10% with the lock hold time exceeding the acquisition time. Will be interesting to lower both loop bounds as well.

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
Please read the FAQ at