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

[Ingo Molnar <mingo@elte.hu>]

* Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> > but couldnt you implement atomic_dec_return() with the ll/sc 
> > instructions? Something like:
> > 
> > repeat:
> >        ldrex   r1, [r0]
> >        sub     r1, r1, #1
> >        strex   r2, r1, [r0]
> >        orrs    r0, r2, r1
> >        jneq    repeat
> > 
> > (shot-in-the-dark guess at ARMv6 assembly)
> 
> atomic_dec_return() would be:
> 
> 1:	ldrex	r1, [r0]
> 	sub	r1, r1, #1
> 	strex	r2, r1, [r0]
> 	teq	r2, #0
> 	bne	1b
> 	@ result in r1
> 
> But that's not really the main point Nico's making.  Yes, on ARMv6 
> there is little difference.  However, ARMv6 is _not_ mainstream yet.  
> The previous generation which do not have this is currently 
> mainstream.

i think there is some miscommunication here. I am actually on your side, 
and i spent all my day enabling the best mutex variant on both the v5 
and v6 version of your CPU. What we were doing was to discuss the 
details of getting there. So dont shoot the messenger, ok?

This is Nico's point i replied to:

> > [...] 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. [...]

and this was my reply:

> i'm curious, how would this ARMv6 solution look like, and what would 
> be the advantages over the atomic swap based variant?

to which Nico replied with an ll/sc implementation, which very much 
looked like atomic_dec_return(). That's all i said. Nobody is trying to
shut out anything from anywhere, and certainly not me. I am _enabling_
your stuff. I'm just trying to find the most maintainable and still most 
flexible solution.

> Nico's point still stands though - and I'd like to ask a more direct 
> question.  There is an efficient implementation for ARMv5 CPUs which 
> it appears we're being denied the ability to use.

do you realize that i've enabled this efficient implementation via 
CONFIG_MUTEX_XCHG_ALGORITHM? Do you realize that you _dont_ have to use 
extremely heavy IRQ-disabling ops on ARM to enable mutexes? Do you 
realize that what we are down to now are 1-2 instructions of 
differences?

The discussion was not about ARMv5 at all. The discussion was about the 
claim that 'ARMv6 is somehow magical that it needs its own stuff'. No it 
isnt magical, it's a sane CPU that can implement a sane 
atomic_dec_return(), or even better, a sane atomic_*_call_if_*() 
primitive. Or whatever primitive we end up having - i dont mind if it's 
called __mutex_whatever, as long as it has a _well defined_ meaning.

what i _DONT_ want is some over-opaque per-arch thing that will again 
escallate into the same situation as semaphores: 23 different 
implementations nobody is able to change at once, nobody is able to add 
features or debugging to, and by today there's probably is no single 
person on this planet who knows all 23 of them to begin with.

if you sense me trying to avoid something then that's it: ambiguities in 
the arch-level implementation, because they end up stiffling the generic 
code.

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