From: Alan Stern <stern@rowland.harvard.edu>
To: "Paul E. McKenney" <paulmck@linux.ibm.com>
Cc: David Goldblatt <davidtgoldblatt@gmail.com>,
<mathieu.desnoyers@efficios.com>,
Florian Weimer <fweimer@redhat.com>, <triegel@redhat.com>,
<libc-alpha@sourceware.org>, <andrea.parri@amarulasolutions.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>, <dlustig@nvidia.com>,
<linux-arch@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Linux: Implement membarrier function
Date: Fri, 14 Dec 2018 16:39:34 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1812141404450.1570-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <20181214184344.GW4170@linux.ibm.com>
On Fri, 14 Dec 2018, Paul E. McKenney wrote:
> I would say that sys_membarrier() has zero-sized read-side critical
> sections, either comprising a single instruction (as is the case for
> synchronize_sched(), actually), preempt-disable regions of code
> (which are irrelevant to userspace execution), or the spaces between
> consecutive pairs of instructions (as is the case for the newer
> IPI-based implementation).
>
> The model picks the single-instruction option, and I haven't yet found
> a problem with this -- which is no surprise given that, as you say,
> an actual implementation makes this same choice.
I believe that for RCU tests the LKMM gives the same results for
length-zero critical sections interspersed between all the instructions
and length-one critical sections surrounding all instructions (except
synchronize_rcu). But the proof is tricky and I haven't checked it
carefully.
> > > The other thing that took some time to get used to is the possibility
> > > of long delays during sys_membarrier() execution, allowing significant
> > > execution and reordering between different CPUs' IPIs. This was key
> > > to my understanding of the six-process example, and probably needs to
> > > be clearly called out, including in an example or two.
> >
> > In all the examples I'm aware of, no more than one of the IPIs
> > generated by each sys_membarrier call really matters. (Of course,
> > there's no way to know in advance which one it will be, so you have to
> > send an IPI to every CPU.) The execution delays and reordering
> > between different CPUs' IPIs don't appear to be significant.
>
> Well, there are litmus tests that are allowed in which the allowed
> execution is more easily explained in terms of delays between different
> CPUs' IPIs, so it seems worth keeping track of.
>
> There might be a litmus test that can tell the difference between
> simultaneous and non-simultaneous IPIs, but I cannot immediately think of
> one that matters. Might be a failure of imagination on my part, though.
P0 P1 P2
Wc=1 [mb01] Rb=1
memb Wa=1 Rc=0
Ra=0 Wb=1 [mb02]
The IPIs have to appear in the positions shown, which means they cannot
be simultaneous. The test is allowed because P2's reads can be
reordered.
Alan
next prev parent reply other threads:[~2018-12-14 21:39 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8736rldyzm.fsf@oldenburg.str.redhat.com>
[not found] ` <1543444466.5493.220.camel@redhat.com>
[not found] ` <87y39c2dsg.fsf@oldenburg.str.redhat.com>
[not found] ` <1689938209.14804.1543502662882.JavaMail.zimbra@efficios.com>
[not found] ` <20181129150433.GH4170@linux.ibm.com>
[not found] ` <CAHD6eXcvx1bskbp-X+vuMYoMQiCLOt0PiCZ5FT1yFsda9Ud-yA@mail.gmail.com>
2018-12-06 21:54 ` [PATCH] Linux: Implement membarrier function Paul E. McKenney
2018-12-10 16:22 ` Alan Stern
2018-12-10 18:25 ` Paul E. McKenney
2018-12-11 16:21 ` Alan Stern
2018-12-11 19:08 ` Paul E. McKenney
2018-12-11 20:09 ` Alan Stern
2018-12-11 21:22 ` Paul E. McKenney
2018-12-12 17:07 ` Paul E. McKenney
2018-12-12 18:04 ` Alan Stern
2018-12-12 19:42 ` Paul E. McKenney
2018-12-12 21:32 ` Alan Stern
2018-12-12 21:52 ` Paul E. McKenney
2018-12-12 22:12 ` Alan Stern
2018-12-12 22:49 ` Paul E. McKenney
2018-12-13 15:49 ` Alan Stern
2018-12-14 0:20 ` Paul E. McKenney
2018-12-14 2:26 ` Alan Stern
2018-12-14 5:20 ` Paul E. McKenney
2018-12-14 15:31 ` Alan Stern
2018-12-14 18:43 ` Paul E. McKenney
2018-12-14 21:39 ` Alan Stern [this message]
2018-12-16 18:51 ` Paul E. McKenney
2018-12-17 16:02 ` Alan Stern
2018-12-17 18:32 ` Paul E. McKenney
2018-12-12 22:19 ` Paul E. McKenney
2018-12-11 6:42 ` David Goldblatt
2018-12-11 14:49 ` Paul E. McKenney
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=Pine.LNX.4.44L0.1812141404450.1570-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=boqun.feng@gmail.com \
--cc=davidtgoldblatt@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=fweimer@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=libc-alpha@sourceware.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mathieu.desnoyers@efficios.com \
--cc=npiggin@gmail.com \
--cc=paulmck@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=triegel@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).