* Linus Torvalds <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
