Re: [PATCH v6 4/5] MCS Lock: Barrier corrections

[Ingo Molnar <mingo@kernel.org>]

* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> On Thu, Nov 21, 2013 at 08:25:59PM -0800, Linus Torvalds wrote:
>
> [...]
> 
> > I do care deeply about reality, particularly of architectures that 
> > actually matter. To me, a spinlock in some theoretical case is 
> > uninteresting, but a efficient spinlock implementation on a real 
> > architecture is a big deal that matters a lot.
> 
> Agreed, reality and efficiency are the prime concerns.  Theory 
> serves reality and efficiency, but definitely not the other way 
> around.
> 
> But if we want locking primitives that don't rely solely on atomic 
> instructions (such as the queued locks that people have been putting 
> forward), we are going to need to wade through a fair bit of theory 
> to make sure that they actually work on real hardware.  Subtle bugs 
> in locking primitives is a type of reality that I think we can both 
> agree that we should avoid.
> 
> Or am I missing your point?

I think one point Linus wanted to make that it's not true that Linux 
has to offer a barrier and locking model that panders to the weakest 
(and craziest!) memory ordering model amongst all the possible Linux 
platforms - theoretical or real metal.

Instead what we want to do is to consciously, intelligently _pick_ a 
sane, maintainable memory model and offer primitives for that - at 
least as far as generic code is concerned. Each architecture can map 
those primitives to the best of its abilities.

Because as we increase abstraction, as we allow more and more complex 
memory ordering details, so does maintainability and robustness 
decrease. So there's a very real crossover point at which point 
increased smarts will actually hurt our code in real life.

[ Same goes for compilers, we draw a line: for example we generally
  turn off strict aliasing optimizations, or we turn off NULL pointer
  check elimination optimizations. ]

I'm not saying this to not discuss theoretical complexities - I'm just 
saying that the craziest memory ordering complexities are probably 
best dealt with by agreeing not to use them ;-)

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>