Re: [patch 04/15] Generic Mutex Subsystem, add-atomic-call-func-x86_64.patch

[Nicolas Pitre <nico@cam.org>]

On Tue, 20 Dec 2005, Russell King wrote:

> On Tue, Dec 20, 2005 at 11:35:22AM -0500, Nicolas Pitre wrote:
> > So 14 instructions total with preemption disabling, and that's with the 
> > best implementation possible by open coding everything instead of 
> > relying on generic functions/macros.
> 
> I agree with your analysis Nicolas.
> 
> However, don't forget to compare this with our existing semaphore
> implementation which is 9 instructions, or 8 for the SMP version.
> 
> In total, this means that mutexes will be _FAR MORE EXPENSIVE_ on ARM
> than our semaphores.

I don't follow you at all.  I'm arguing that mutexes are much less 
expensive than any semaphore implementation (except on SMP where 
semaphores and mutexes will probably look the same).

> Forcing architectures down the "lets make everything generic" path
> does not always hack it.  It can't do by its very nature.  Generic
> implementations are *always* sub-optimal and it is pretty clear
> that any gain that mutexes _may_ give is completely wasted on ARM
> by the overhead of having a generic framework imposed upon us.

Agreed.  And that's why I'm suggesting that the mutex locking/unlocking 
fast path should be architecture specific.  And to that effect I'm 
working on a patch against Ingo's mutex code to illustrate my point.

What should still remain generic is the contention fallback.  That's 
where the actual complexity lives and that part doesn't have to be 
optimized for best inline performances.


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/