Messages in this thread | | | Date | Thu, 07 Feb 2002 11:25:14 -0800 | From | Andrew Morton <> | Subject | Re: [RFC] New locking primitive for 2.5 |
| |
Robert Love wrote: > > On Thu, 2002-02-07 at 10:38, Martin Wirth wrote: > > This is a request for comment on a new locking primitive > > called a combilock. > > Interesting ... > > The question I raise is, how many locks do we have where we have a > single resource we lock where in some codepaths the lock is used for > short duration and in other places the lock is long-duration?
Quite a few. Significant ones. pagemap_lru_lock and lru_list_lock come to mind.
> It would be useful to identify a few locks where this would benefit and > apply the appropriate combi variant and do some benchmarking. > > 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.
I need to think about all of this some more...
> ... > > > To really take any benefit from a preemptible kernel a lot of spin locks > > will have to be replaced by mutex locks. The combi-lock approach may > > convince more people who typically fear the higher scheduling pressure > > of sleeping locks to do so, if they can decide on each instance which > > approach (spin of sleep) will be taken. > > We shouldn't engage in wholesale changing of spinlocks to semaphores > without a priority-inheritance mechanism. And _that_ is the bigger > issue ...
hmmm.
Let's back off a bit. What are we trying to achieve here? What problem are we trying to solve? Is it to allow preemptability inside the infamous long-held locks? If so then I'd favour a piecemeal approach to handling each one, rather than magic bullets. Now it may be that certain of the locks are best handled via a new primitive, but that's not obviously true at this time, 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/
| |