Re: RFC: Ideal Adaptive Spinning Conditions

From: Rik van Riel
Date: Sat Apr 03 2010 - 21:51:06 EST

On 03/31/2010 10:25 PM, Steven Rostedt wrote:
On Wed, 2010-03-31 at 19:13 -0700, Darren Hart wrote:
Steven Rostedt wrote:
On Wed, 2010-03-31 at 16:21 -0700, Darren Hart wrote:

o What type of lock hold times do we expect to benefit?

0 (that's a zero) :-p

I haven't seen your patches but you are not doing a heuristic approach,
are you? That is, do not "spin" hoping the lock will suddenly become
free. I was against that for -rt and I would be against that for futex

I'm not sure what you're getting at here. Adaptive spinning is indeed
hoping the lock will become free while you are spinning and checking
it's owner...

I'm talking about the original idea people had of "lets spin for 50us
and hope it is unlocked before then", which I thought was not a good

Maybe not a good idea when running on bare metal, but it
could be a big help when running virtualized.

A lock with a short hold time can, occasionally, have a
very long hold time, when the VCPU holding the lock is
preempted by the host/hypervisor.

An adaptive lock would spin-and-acquire if the lock holder
is running, while turning into a sleep lock when the lock
holder has been preempted.

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