Re: [Ksummit-discuss] [TECH TOPIC] Memory model, using ISO C++11 atomic ops

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

On Fri, Jul 22, 2016 at 11:34:35AM +0100, David Howells wrote:
> Earlier this year we had a discussion of the possibilities of using ISO C++11
> atomic operations inside the kernel to implement kernel atomic ops of sorts
> various, posted here:
> 
> 	Subject: [RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics
> 	Date: Wed, 18 May 2016 16:10:37 +0100
> 
> Is it worth getting together to discuss these in person in one of the tech
> slots - especially if there are some gcc or llvm people available at plumbers
> who could join in?
> 
> 
> Further, Paul McKenney and others are assembling a memory model description.

We are attempting to automate memory-barriers.txt, so that you could
provide fragments of C code, and the tool would tell you whether a given
outcome happens always, sometimes, or never.  The current prototype
handles memory accesses, memory barriers, and RCU, but not yet locking
or read-modify-write atomics (though there is some vestigal support for
RMW atomics).  We are currently playing whack-a-mole with odd corner cases
of various architectures' memory models.  We are therefore also working
on ways of handling the resulting uncertainty.  Good clean fun!  ;-)

> Do we want to consider loosening up the kernel memory model?
> 
> Currently, for example, locks imply semi-permeable barriers that are not tied
> to the lock variable - but, as I understand it, this may not hold true on all
> arches, and on those arches an extra memory barrier would be required.  For
> example, { LOCK(A), UNLOCK(A), LOCK(B), UNLOCK(B) } would not imply a full
> memory barrier in the middle.

Agreed, the current version of memory-barriers.txt documents the fact
that an unlock/lock sequence does not imply a full memory barrier:

	Similarly, the reverse case of a RELEASE followed by an ACQUIRE
	does not imply a full memory barrier.

If we are going to talk about changing this, we should most definitely
include a powerpc arch maintainer.

> Also, we have read and write memory barrier constructs - but not all CPUs have
> such things, some instead have acquire and release.  Would it be worth having
> higher level constructs that encapsulate what you're trying to do and select
> the most appropriate barrier from the available choices?  For instance, we
> have a fair few circular buffers, with linux/circ_buf.h providing some useful
> bits.  Should we provide circular buffering barrier constructs?
> 
> 
> If we do this, Will Deacon, Peter Zijlstra and Paul McKenney should definitely
> be there.  I would suggest Jakub Jelinek and Ramana Radhakrishnan as gcc
> representatives.  I don't know anyone from LLVM.

Alan Stern should be included, as he is the author of the most recent
version of the prototype formalized memory model (including the current
extremely nice formal model of RCU!), Luc Maranget as the author of
the previous version, Jade Alglave as author of the first version and
founder of this project, and Andrea Parri for his many contributions to
recent models.

Shouldn't we also include experts on other SMP architectures?

							Thanx, Paul