From: Andrea Parri <andrea.parri@amarulasolutions.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH] refcount_t: add ACQUIRE ordering on success for dec(sub)_and_test variants
Date: Wed, 30 Jan 2019 04:33:33 +0100 [thread overview]
Message-ID: <20190130032701.GA3739@andrea> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612BA4B99139@IRSMSX102.ger.corp.intel.com>
> So, you are saying that ACQUIRE does not guarantee that "po-later stores
> on the same CPU and all propagated stores from other CPUs
> must propagate to all other CPUs after the acquire operation "?
> I was reading about acquire before posting this and trying to understand,
> and this was my conclusion that it should provide this, but I can easily be wrong
> on this.
>
> Andrea, Peter, could you please comment?
Short version: I am not convinced by the above sentence, and I suggest
to remove it (as done in
http://lkml.kernel.org/r/20190128142910.GA7232@andrea ).
---
To elaborate: I think that we should first discuss the meaning of that
"[...] after the acquire operation (does)", because there is no notion
of "ACQUIRE (or more generally, load) propagation" in the LKMM:
Stores propagate (after being executed) to other CPUs. Loads _execute_
(possibly multiple times /speculatively, but this is irrelevant for the
discussion below).
A detailed, but still informal, description of these concepts is in:
tools/memory-model/Documentation/explanation.txt
(c.f., in particular, section "AN OPERATIONAL MODEL"); I can illustrate
them with an example:
{ initially: x=0, y=0; }
CPU0 CPU1
--------------------------------------
LOAD-ACQUIRE x=0 LOAD y=1
STORE y=1
In this scenario,
a) CPU0's "LOAD-ACQUIRE x=0" executes before CPU0's "STORE y=1"
executes (this is guaranteed by the ACQUIRE),
b) CPU0's "STORE y=1" executes before "STORE y=1" propagates to
CPU1 (a store cannot be propagated before being executed),
c) CPU0's "STORE y=1" propagates to CPU1 before CPU1's "LOAD y=1"
executes (since CPU1 "sees the store").
The example also illustrates the following property:
ACQUIRE guarantees that po-later stores on the same CPU must
propagate to all other CPUs after the acquire _executes_.
(combine (a) and (b) ).
OTOH, please notice that:
ACQUIRE does _NOT_ guarantee that all propagated stores from
other CPUs (to the CPU executing the ACQUIRE) must propagate
to all other CPUs after the acquire operation _executes_.
In fact, we've already seen how full barriers can be used to break such
"guarantee"; for example, in
{ initially: x=0, y=0; }
CPU0 CPU1 ...
---------------------------------------------------
STORE x=1 LOAD x=1
FULL-BARRIER
LOAD-ACQUIRE y=0
the full barrier forces CPU0's "STORE x=1" (seen by/propagated to CPU1)
to be propagated to all CPUs _before_ "LOAD-ACQUIRE y=0" is executed.
Does this make sense?
> > Is ACQUIRE strictly stronger than control dependency?
>
> In my understanding yes.
+1 (or we have a problem)
>
> > It generally looks so unless there is something very subtle that I am
> > missing. If so, should we replace it with just "RELEASE ordering +
> > ACQUIRE ordering on success"? Looks simpler with less magic trickery.
>
> I was just trying to mention all the applicable orderings/guarantees.
> I can remove "control dependency" part if it is easier for people to understand
> (the main goal of documentation).
This sounds like a good idea; thank you, Dmitry, for pointing this out.
Andrea
>
> Best Regards,
> Elena.
next prev parent reply other threads:[~2019-01-30 3:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 12:09 [PATCH] refcount_t: add ACQUIRE ordering on success for dec(sub)_and_test variants Elena Reshetova
2019-01-28 14:29 ` Andrea Parri
2019-01-29 9:51 ` Peter Zijlstra
2019-01-29 13:39 ` Reshetova, Elena
2019-01-29 14:00 ` Dmitry Vyukov
2019-01-29 17:37 ` Reshetova, Elena
2019-01-30 3:33 ` Andrea Parri [this message]
2019-01-30 10:19 ` Reshetova, Elena
2019-01-30 10:34 ` Dmitry Vyukov
2019-01-30 11:18 [PATCH v2] Adding smp_acquire__after_ctrl_dep barrier Elena Reshetova
2019-01-30 11:18 ` [PATCH] refcount_t: add ACQUIRE ordering on success for dec(sub)_and_test variants Elena Reshetova
2019-01-30 12:31 ` Andrea Parri
2019-01-30 14:21 ` Peter Zijlstra
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=20190130032701.GA3739@andrea \
--to=andrea.parri@amarulasolutions.com \
--cc=dvyukov@google.com \
--cc=elena.reshetova@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
/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).