Messages in this thread | | | Date | Thu, 07 Feb 2002 12:06:22 -0800 | From | Andrew Morton <> | Subject | Re: [RFC] New locking primitive for 2.5 |
| |
Dave Hansen wrote: > > Andrew Morton wrote: > > Robert Love wrote: > >>On Thu, 2002-02-07 at 10:38, Martin Wirth wrote: > >>Some of the talk I've heard has been toward an adaptive lock. These are > >>locks like Solaris's that can spin or sleep, usually depending on the > >>state of the lock's holder. Another alternative, which I prefer since > >>it is much less overhead, is a lock that spins-then-sleeps > >>unconditionally. > > I dunno. The spin-a-bit-then-sleep lock has always struck me as > > i_dont_know_what_the_fuck_im_doing_lock(). Martin's approach puts > > the decision in the hands of the programmer, rather than saying > > "Oh gee I goofed" at runtime. > > The spin-then-sleep lock could be interesting as a replacement for the > BKL in places where a semaphore causes performance degredation. In > quite a few places where we replaced the BKL with a more finely grained > semapore (not a spinlock because we needed to sleep during the hold), > instead of spinning for a bit, it would schedule instead. This was bad > :). Spin-then-sleep would be great behaviour in this situation.
But surely you *knew*, from inspection, which code paths needed a spinning lock, and which code paths needed a sleeping lock?
Assuming the answer is "yes" then a nice fix would be to use two separate locks - one which spins and one which sleeps.
Now, if the resource which is being protected truly cannot be split up into spin-protected and sleep-protected sections then a lock which can be atomically converted from spinning to sleeping at the programmer's discretion seems appropriate.
A dynamic lock which says "we've spun for too long, let's sleep" seems to be a tradeoff between programmer effort and efficiency, and a bad one at that.
Possibly the locks could become more adaptive, and could, at each call site, "learn" the expected spintime. But it all seems too baroque to me.
- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |