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

David Howells dhowells at redhat.com
Fri Jul 22 10:34:35 UTC 2016


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

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.

David


More information about the Ksummit-discuss mailing list