Messages in this thread | | | Date | Wed, 16 Dec 1998 16:39:22 +1100 | From | Richard Gooch <> | Subject | Re: User-level locking |
| |
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/
| |