From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
mingo@kernel.org
Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com,
will.deacon@arm.com, peterz@infradead.org, boqun.feng@gmail.com,
npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr, akiyks@gmail.com
Subject: Q&A from "Concurrency with tools/memory-model"
Date: Thu, 15 Nov 2018 14:56:30 -0800 [thread overview]
Message-ID: <20181115225630.GA30917@linux.ibm.com> (raw)
Hello!
Good turnout and some good questions here in Vancouver BC, please see
below for rough notes. ;-)
Thanx, Paul
------------------------------------------------------------------------
"Concurrency with tools/memory-model"
Andrea Parri presenting.
Rough notes of Q&A.
o Want atomic bit operation.
o But smp_read_barrier_depends() not there, so how to note pairing?
A: Note the dependency as the other end of the pairing.
o Speculation barriers, as in Spectre and Meltdown? A: This would
require adding timing, not in the immediate future.
o What ordering does system calls provide? A: None that we know of.
Boqun: Userspace needs to explicitly provide the needed ordering
when interacting with the kernel. Some architectures do provide
full barriers, but not to be counted on.
o Why herd7? A: Based on other formalizations -- note that herd7
had a number of hardware models. Paul: Plus the founder of the
LKMM project is a co-author of herd, which might have had some
effect.
o Why not also model interrupts and NMIs? Promela and spin have
been used for this. A: Cannot currently model them. You can
emulated them with additional threads and locks, if you wish.
Vincent Nimal and Lihao Liang have done some academic work on
these topics.
next reply other threads:[~2018-11-15 22:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 22:56 Paul E. McKenney [this message]
2018-11-27 11:55 ` Q&A from "Concurrency with tools/memory-model" Andrea Parri
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=20181115225630.GA30917@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@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