From: Boqun Feng <boqun.feng@gmail.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
linux-kernel@vger.kernel.org, kernel-team@android.com,
Akira Yokosawa <akiyks@gmail.com>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Daniel Lustig <dlustig@nvidia.com>,
David Howells <dhowells@redhat.com>,
Ingo Molnar <mingo@kernel.org>,
Jade Alglave <j.alglave@ucl.ac.uk>,
linux-arch@vger.kernel.org, Luc Maranget <luc.maranget@inria.fr>,
Nicholas Piggin <npiggin@gmail.com>,
"Paul E. McKenney" <paulmck@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2] lkmm/docs: Correct ->prop example with additional rfe link
Date: Mon, 29 Jul 2019 13:50:44 +0800 [thread overview]
Message-ID: <20190729055044.GC26905@tardis> (raw)
In-Reply-To: <20190728153544.GA87531@google.com>
[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]
On Sun, Jul 28, 2019 at 11:35:44AM -0400, Joel Fernandes wrote:
[...]
> > > > > +load of y (rfe link), P2's smp_store_release() ensures that P2's load
> > > > > +of y executes before P2's store to z (second fence), which implies that
> > > > > +that stores to x and y propagate to P2 before the smp_store_release(), which
> > > > > +means that P2's smp_store_release() will propagate stores to x and y to all
> > > > > +CPUs before the store to z propagates (A-cumulative property of this fence).
> > > > > +Finally P0's load of z executes after P2's store to z has propagated to
> > > > > +P0 (rfe link).
> > > >
> > > > Again, a better change would be simply to replace the two instances of
> > > > "fence" in the original text with "cumul-fence".
> > >
> > > Ok that's fine. But I still feel the rfe is not a part of the cumul-fence.
> > > The fences have nothing to do with the rfe. Or, I am missing something quite
> > > badly.
> > >
> > > Boqun, did you understand what Alan is saying?
> > >
> >
> > I think 'cumul-fence' that Alan mentioned is not a fence, but a
> > relation, which could be the result of combining a rfe relation and a
> > A-cumulative fence relation. Please see the section "PROPAGATION ORDER
> > RELATION: cumul-fence" or the definition of cumul-fence in
> > linux-kernel.cat.
> >
> > Did I get you right, Alan? If so, your suggestion is indeed a better
> > change.
>
> To be frank, I don't think it is better if that's what Alan meant. It is
> better to be explicit about the ->rfe so that the reader walking through the
> example can clearly see the ordering and make sense of it.
>
> Just saying 'cumul-fence' and then hoping the reader sees the light is quite
> a big assumption and makes the document less readable.
>
After a bit more rereading of the document, I still think Alan's way is
better ;-)
Please consider the context of paragraph, this is an explanation of an
example, which is about the previous sentence:
The formal definition of the prop relation involves a coe or
fre link, followed by an arbitrary number of cumul-fence links,
ending with an rfe link.
, so using "cumul-fence" actually matches the definition of ->prop.
For the ease of readers, I can think of two ways:
1. Add a backwards reference to cumul-fence section here, right
before using its name.
2. Use "->cumul-fence" notation rather than "cumul-fence" here,
i.e. add an arrow "->" before the name to call it out that name
"cumul-fence" here stands for links/relations rather than a
fence/barrier. Maybe it's better to convert all references to
links/relations to the "->" notations in the whole doc.
Thoughts?
Regards,
Boqun
> I mean the fact that you are asking Alan for clarification, means that it is
> not that obvious ;)
>
> thanks,
>
> - Joel
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-29 5:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-28 3:13 [PATCH v2] lkmm/docs: Correct ->prop example with additional rfe link Joel Fernandes (Google)
2019-07-28 14:48 ` Alan Stern
2019-07-28 14:48 ` Alan Stern
2019-07-28 15:19 ` Joel Fernandes
2019-07-28 15:28 ` Boqun Feng
2019-07-28 15:35 ` Joel Fernandes
2019-07-29 5:50 ` Boqun Feng [this message]
2019-07-29 12:17 ` Joel Fernandes
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=20190729055044.GC26905@tardis \
--to=boqun.feng@gmail.com \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=kernel-team@android.com \
--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=paulmck@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.