lkml.org 
[lkml]   [2002]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:4.043 / U:0.348 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site