From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
David Howells <dhowells@redhat.com>,
Masanari Iida <standby24x7@gmail.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] doc: memory-barriers.txt: Minor correction in Control dependencies
Date: Wed, 13 Aug 2014 15:49:43 -0700 [thread overview]
Message-ID: <20140813224943.GC4752@linux.vnet.ibm.com> (raw)
In-Reply-To: <1407797503-24727-1-git-send-email-bobby.prani@gmail.com>
On Mon, Aug 11, 2014 at 06:51:39PM -0400, Pranith Kumar wrote:
> Minor corrections in memory-barriers.txt document.
>
> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
> ---
> Documentation/memory-barriers.txt | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index abec3f9..41a6c9c 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -627,7 +627,7 @@ proving the value of 'a', and the pair of barrier() invocations are
> required to prevent the compiler from pulling the two identical stores
> to 'b' out from the legs of the "if" statement.
>
> -It is important to note that control dependencies absolutely require a
> +It is important to note that control dependencies absolutely require
> a conditional. For example, the following "optimized" version of
> the above example breaks ordering, which is why the barrier() invocations
> are absolutely required if you have identical stores in both legs of
> @@ -652,7 +652,7 @@ for example, as follows:
> do_something();
> } else {
> barrier();
> - ACCESS_ONCE(b) = q / 3;
> + ACCESS_ONCE(b) = q / 2;
> do_something_else();
> }
This one is gone due to the two-legged "if" statements being reworked.
> @@ -710,7 +710,7 @@ x and y both being zero:
>
> The above two-CPU example will never trigger the assert(). However,
> if control dependencies guaranteed transitivity (which they do not),
> -then adding the following two CPUs would guarantee a related assertion:
> +then adding the following CPU would guarantee a related assertion:
>
> CPU 2
> =====================
> @@ -719,8 +719,8 @@ then adding the following two CPUs would guarantee a related assertion:
> assert(!(r1 == 2 && r2 == 1 && x == 2)); /* FAILS!!! */
>
> But because control dependencies do -not- provide transitivity, the
> -above assertion can fail after the combined four-CPU example completes.
> -If you need the four-CPU example to provide ordering, you will need
> +above assertion can fail after the combined three-CPU example completes.
> +If you need the three-CPU example to provide ordering, you will need
> smp_mb() between the loads and stores in the CPU 0 and CPU 1 code fragments,
> that is, just before or just after the "if" statements.
Nikolay Samofatov beat you to this one by a couple of weeks.
Nevertheless, thank you for your careful review!
Thanx, Paul
prev parent reply other threads:[~2014-08-13 22:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 22:51 [PATCH] doc: memory-barriers.txt: Minor correction in Control dependencies Pranith Kumar
2014-08-11 22:51 ` [PATCH] doc: memory-barriers.txt: Add barrier() to provide ordering Pranith Kumar
2014-08-13 22:50 ` Paul E. McKenney
2014-08-11 22:51 ` [PATCH] sched: Remove ACCESS_ONCE() for jiffies Pranith Kumar
2014-08-12 5:55 ` Peter Zijlstra
2014-08-12 14:42 ` Pranith Kumar
2014-08-12 22:11 ` David Rientjes
2014-08-11 22:51 ` [PATCH] compiler.h: Move __memory_barrier() use to compiler-intel.h Pranith Kumar
2014-08-11 22:51 ` Pranith Kumar
2014-08-13 22:49 ` Paul E. McKenney [this message]
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=20140813224943.GC4752@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=bobby.prani@gmail.com \
--cc=dhowells@redhat.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=standby24x7@gmail.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 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.