Re: [patch 00/21] mutex subsystem, -V14

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxx> wrote:

> I _think_ your patch is the right approach, because most architectures 
> are likely to do their own fast-paths for mutexes, and as such the 
> generic ones are more of a template for how to do it, and hopefilly 
> aren't that performance critical.

yeah, i think so too. We've got 3 architectures done in assembly so far, 
and it seems people like optimizing such code. Also, since the generic 
code does all the boring slowpath stuff, the architecture can 
concentrate on the fun part alone: to make the fastpath really fast.  
The generic code is still in full control of all the mutex semantics, 
and can ignore asm/mutex.h when it wants/needs to. So i'm quite happy 
with the current design and i'm not against more per-arch assembly fun, 
at all.

there's one exception i think: atomic-xchg.h was pretty optimal on ARM, 
and i'd expect it to be pretty optimal on the other atomic-swap 
platforms too. So maybe we should specify atomic_xchg() to _not_ imply a 
full barrier - it's a new API anyway. We cannot embedd the barrier 
within atomic_xchg(), because the barrier is needed at different ends 
for lock and for unlock, and adding two barriers would be unnecessary.

asm-generic/mutex-dec.h is less optimal (and thus less critical), and i 
can see no easy way to modify it, because i think it would be quite 
confusing to enforce 'lock' ordering for atomic_dec_return(), and 
'unlock' ordering for atomic_inc_return(). We cannot remove the existing 
barriers either (and add them explicitly), because there are existing 
users of these primitives. (although we could add explicit barriers to 
those too - but probably not worth the trouble)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/