Re: User-level locking
Richard Gooch (rgooch@atnf.csiro.au)
Wed, 16 Dec 1998 16:39:22 +1100
Colin Plumb writes:
> 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.
As usual, you have presented an excellent, well thought out and
presented analysis. I'd agree that 5 calls to sched_yield() may be
excessive. I think that at least one is appropriate (give the other
thread a chance to unlock), further yields are probably of marginal
benefit.
Regards,
Richard....
-
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/