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

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Thu, Nov 21, 2013 at 08:25:59PM -0800, Linus Torvalds wrote:
> On Thu, Nov 21, 2013 at 8:08 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > It is not the architecture that matters here, it is just a definition of
> > what ordering guarantees the locking primitives provide, independent of
> > the architecture.
> 
> So we definitely come from very different backgrounds.

Agreed, and I am pretty sure we are talking past each other.

> I don't care one *whit* about theoretical lock orderings. Not a bit.

If by theoretical lock orderings, you mean whether or not unlock+lock
acts as a full memory barrier, we really do have some code in the kernel
that relies on this.  So we either need to have find and change this
code or we need unlock+lock to continue to act as a full memory barrier.
Making RCU stop relying on this is easy because all the code that assumes
unlock+lock is a full barrier is on slow paths anyway.  Other subsystems
might be in different situations.

If you mean something else by theoretical lock orderings, I am sorry,
but I am completely failing to see what it might be.

> 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?

							Thanx, Paul

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