Re: RFC: Ideal Adaptive Spinning Conditions

From: Darren Hart
Date: Mon Apr 05 2010 - 10:07:04 EST

john cooper wrote:
Darren Hart wrote:
Right, and I'm looking to provide some kernel assistance for userspace
spinlocks here, and am targeting short lived critical sections as well.

What did you have in mind beyond existing mechanisms
which address sibling contention?

One scenario which AFAICT isn't yet addressed is that
of a userspace spin lock holder taking a scheduling
preemption which may result in other threads piling up
on the lock orders of magnitude beyond normal wait times,
until the lock holder is rescheduled.

That is an excellent example.

Another is the highly fragile performance characteristics of spinlocks with sched_yield() implementations lead to. As sched_yield implementations change, the scheduling behavior of the spinning tasks also changes. As the number of cores grows, more performance tuning is required. Sched_yield() essentially allows the spinner to spin for a time and then get off the cpu for a time - but it doesn't have any idea about the state of the lock owner and it's pure chance if the spinning task with schedule back in at an opportune time, or if it will just be adding to the scheduling overhead and CPU resources the owner is still trying to acquire.

The idea here is to leverage the additional information we have in the kernel to make more intelligent decisions about how long to spin (as well as how many tasks should spin).

Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
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