* Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>