From: David Howells <dhowells@redhat.com>
To: ksummit-discuss@lists.linuxfoundation.org
Cc: jakub@redhat.com, peterz@infradead.org, ramana.radhakrishnan@arm.com
Subject: [Ksummit-discuss] [TECH TOPIC] Memory model, using ISO C++11 atomic ops
Date: Fri, 22 Jul 2016 11:34:35 +0100 [thread overview]
Message-ID: <15500.1469183675@warthog.procyon.org.uk> (raw)
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
next reply other threads:[~2016-07-22 10:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 10:34 David Howells [this message]
2016-07-22 16:44 ` Paul E. McKenney
2016-07-25 17:14 ` Luis R. Rodriguez
2016-07-26 6:09 ` Hannes Reinecke
2016-07-26 13:10 ` Alan Stern
2016-07-26 13:35 ` Paul E. McKenney
2016-07-29 1:06 ` Steven Rostedt
2016-07-26 15:23 ` Hannes Reinecke
2016-07-26 22:40 ` Paul E. McKenney
2016-07-23 20:21 ` Benjamin Herrenschmidt
2016-07-26 15:11 ` David Woodhouse
2016-07-28 10:41 ` Will Deacon
2016-08-02 13:42 ` Peter Zijlstra
2016-08-03 8:49 ` Will Deacon
2016-07-26 15:20 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15500.1469183675@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=jakub@redhat.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=peterz@infradead.org \
--cc=ramana.radhakrishnan@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox