Re: [patch 0/9] mutex subsystem, -V4

[Nicolas Pitre <nico@cam.org>]

On Thu, 22 Dec 2005, Steven Rostedt wrote:

> On Thu, 2005-12-22 at 10:34 -0500, Nicolas Pitre wrote:
> 
> > > Actually just havign asm/mutex.h implement the faspath per-arch and get
> > > rid of all the oddball atomic.h additions would be even better.  While
> > > this means we need per-arch code it also means the code is a lot easier
> > > understandable, and we don't add odd public APIs.
> > 
> > I'm with Christoph here.  Please preserve my 
> > arch_mutex_fast_lock/arch_mutex_fast_unlock helpers.  I did it that way 
> > because the most important thing they bring is flexibility where it is 
> > needed i.e. in architecture specific implementations.  And done that way 
> > the architecture specific part is well abstracted with the minimum 
> > semantics allowing flexibility in the implementation.
> > 
> > I insist on that because, even if ARM currently relies on the atomic 
> > swap behavior, on ARMv6 at least this can be improved even further, but 
> > a special implementation which is neither a fully qualified atomic 
> > decrement nor an atomic swap is needed.  That's why I insist that you 
> > should keep my arch_mutex_fast_lock and friends (rename them if you 
> > wish) and remove __ARCH_WANT_XCHG_BASED_ATOMICS entirely.
> > 
> 
> Not sure how well this is accepted, but would it be acceptable to have
> the mutex_lock and friends covered with the (weak) attribute?
> 
> ie.
> 
> void fastcall __sched __attribute__((weak)) mutex_lock(struct mutex *lock)
> 
> Then let the archs override them if they wish?

Actually, my next request would be for architectures to actually inline 
the fast path if they see benefit.  On ARM, given the tight fast path 
allowed by mutexes, it is indeed beneficial to inline them (the last 
patch of my latest serie does just that).  So weak symbols are not 
really useful in that case.


Nicolas
-
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/