User-level locking

Colin Plumb (colin@nyx.net)
Tue, 15 Dec 1998 22:00:24 -0700 (MST)


Richard Gooch wrote:

> Say spin 5 times, then loop with sched_yield() 5 times, then go to
> sleep (block in kernel).
> The theory is that you first spin waiting for someone else to soon
> release a lock (if they're in a small critical region). Then loop with
> sched_yield() to give someone else a chance (in case the locking
> process is waiting for your timeslice to finish). After that, it's
> probably going to take a long time (>100us) for the lock to be
> released, so hop onto a wait queue.

Spinning a few times seems reasonable. (Although ideally the lock should
have stats on whether it's worthwhile or not.)

But once you're going into the kernel (calling sched_yield()), the
benefit of not just staying there on a wait queue is unclear.

The actual kernel work involved in the sleeping and waking up is
pretty insignificant, once the entry, exit, and schedule() costs are
subtracted.

The only savings is that the process waking you up doesn't have to
go into the kernel to do so. So basically it's half the cost of
making a blocking kernel call.

Okay, so that means that it's worth trying sched_yield() if the chances
of it working (i.e. the lock being free on return) are 50%.

I can believe that for the first call. For the second, I'm dubious.
(Remember, that's 50% of the times that a second call is made, it
succeeds, meaning less than 25% of locks are still contended after two
calls.) For the third through the fifth, it seems pretty implausible.

Thus, while real figures are of course more meaningful than my
intuition, i seems like sched_yield should be called once, if at all,
before blocking in the kernel.

Does anybody have any hard data?

-- 
	-Colin

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