Re: [PATCH tip/core/rcu 2/6] Documentation/memory-barriers.txt: ACCESS_ONCE() provides cache coherence

Re: [PATCH tip/core/rcu 2/6] Documentation/memory-barriers.txt: ACCESS_ONCE() provides cache coherence

[Jon Masters]

Hi Paul,

On 2/17/14 4:26 PM, Paul E. McKenney wrote:

> The ACCESS_ONCE() primitive provides cache coherence, but the
> documentation does not clearly state this.  This commit therefore upgrades
> the documentation.

<snip>

> +     In short, ACCESS_ONCE() provides "cache coherence" for accesses from
> +     multiple CPUs to a single variable.

(ACCESS_ONCE is now READ_ONCE/WRITE_ONCE but the above added the 
original language around cache coherence)

I would argue that we might want to avoid describing it in this manner. 
The hardware provides cache coherency in order to keep a single memory 
location coherent between multiple observers. These kernel macros only 
tell the compiler to perform the load once. They take advantage of the 
properties of coherence in the presence of multiple observers.

Jon.

-- 
Computer Architect

Re: [PATCH tip/core/rcu 2/6] Documentation/memory-barriers.txt: ACCESS_ONCE() provides cache coherence

[Paul E. McKenney]

On Thu, Apr 23, 2020 at 11:36:19PM -0400, Jon Masters wrote:
> Hi Paul,
> 
> On 2/17/14 4:26 PM, Paul E. McKenney wrote:
> 
> > The ACCESS_ONCE() primitive provides cache coherence, but the
> > documentation does not clearly state this.  This commit therefore upgrades
> > the documentation.
> 
> <snip>
> 
> > +     In short, ACCESS_ONCE() provides "cache coherence" for accesses from
> > +     multiple CPUs to a single variable.
> 
> (ACCESS_ONCE is now READ_ONCE/WRITE_ONCE but the above added the original
> language around cache coherence)
> 
> I would argue that we might want to avoid describing it in this manner. The
> hardware provides cache coherency in order to keep a single memory location
> coherent between multiple observers. These kernel macros only tell the
> compiler to perform the load once. They take advantage of the properties of
> coherence in the presence of multiple observers.

You lost me on this one.  Are you advocating that this be described
as constraining the compiler from invalidating the cache coherency
(single-variable sequential consistency) provided by modern hardware?

Just for background, my view is that "cache coherence", like "real time",
is a property of the system that can be destroyed by any component.

							Thanx, Paul

Re: [PATCH tip/core/rcu 2/6] Documentation/memory-barriers.txt: ACCESS_ONCE() provides cache coherence

[Paul E. McKenney]

On Mon, Feb 17, 2014 at 01:40:56PM -0800, Josh Triplett wrote:
> On Mon, Feb 17, 2014 at 01:26:49PM -0800, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > 
> > The ACCESS_ONCE() primitive provides cache coherence, but the
> > documentation does not clearly state this.  This commit therefore upgrades
> > the documentation.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> Punctuation nit below; otherwise:
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> 
> >  Documentation/memory-barriers.txt | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> > index 102dc19c4119..ad6db1d48f1f 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -1249,6 +1249,23 @@ The ACCESS_ONCE() function can prevent any number of optimizations that,
> >  while perfectly safe in single-threaded code, can be fatal in concurrent
> >  code.  Here are some examples of these sorts of optimizations:
> >  
> > + (*) The compiler is within its rights to reorder loads and stores
> > +     to the same variable, and in some cases, the CPU is within its
> > +     rights to reorder loads to the same variable.  This means that
> > +     the following code:
> > +
> > +	a[0] = x;
> > +	a[1] = x;
> > +
> > +     Might result in an older value of x stored in a[1] than in a[0].
> > +     Prevent both the compiler and the CPU from doing this as follows:
> > +
> > +	a[0] = ACCESS_ONCE(x);
> > +	a[1] = ACCESS_ONCE(x);
> > +
> > +     In short, ACCESS_ONCE() provides "cache coherence" for accesses from
> > +     multiple CPUs to a single variable.
> 
> You don't need to "quote" the well-established term "cache coherence".

Good point, fixed and applied your Reviewed-by, thank you!

							Thanx, Paul

> >   (*) The compiler is within its rights to merge successive loads from
> >       the same variable.  Such merging can cause the compiler to "optimize"
> >       the following code:
> > -- 
> > 1.8.1.5
> > 
> 

Re: [PATCH tip/core/rcu 2/6] Documentation/memory-barriers.txt: ACCESS_ONCE() provides cache coherence

[Josh Triplett]

On Mon, Feb 17, 2014 at 01:26:49PM -0800, Paul E. McKenney wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> 
> The ACCESS_ONCE() primitive provides cache coherence, but the
> documentation does not clearly state this.  This commit therefore upgrades
> the documentation.
> 
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

Punctuation nit below; otherwise:
Reviewed-by: Josh Triplett <josh@joshtriplett.org>

>  Documentation/memory-barriers.txt | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 102dc19c4119..ad6db1d48f1f 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -1249,6 +1249,23 @@ The ACCESS_ONCE() function can prevent any number of optimizations that,
>  while perfectly safe in single-threaded code, can be fatal in concurrent
>  code.  Here are some examples of these sorts of optimizations:
>  
> + (*) The compiler is within its rights to reorder loads and stores
> +     to the same variable, and in some cases, the CPU is within its
> +     rights to reorder loads to the same variable.  This means that
> +     the following code:
> +
> +	a[0] = x;
> +	a[1] = x;
> +
> +     Might result in an older value of x stored in a[1] than in a[0].
> +     Prevent both the compiler and the CPU from doing this as follows:
> +
> +	a[0] = ACCESS_ONCE(x);
> +	a[1] = ACCESS_ONCE(x);
> +
> +     In short, ACCESS_ONCE() provides "cache coherence" for accesses from
> +     multiple CPUs to a single variable.

You don't need to "quote" the well-established term "cache coherence".

>   (*) The compiler is within its rights to merge successive loads from
>       the same variable.  Such merging can cause the compiler to "optimize"
>       the following code:
> -- 
> 1.8.1.5
> 

[PATCH tip/core/rcu 2/6] Documentation/memory-barriers.txt: ACCESS_ONCE() provides cache coherence

[Paul E. McKenney]

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>

The ACCESS_ONCE() primitive provides cache coherence, but the
documentation does not clearly state this.  This commit therefore upgrades
the documentation.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 Documentation/memory-barriers.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 102dc19c4119..ad6db1d48f1f 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1249,6 +1249,23 @@ The ACCESS_ONCE() function can prevent any number of optimizations that,
 while perfectly safe in single-threaded code, can be fatal in concurrent
 code.  Here are some examples of these sorts of optimizations:
 
+ (*) The compiler is within its rights to reorder loads and stores
+     to the same variable, and in some cases, the CPU is within its
+     rights to reorder loads to the same variable.  This means that
+     the following code:
+
+	a[0] = x;
+	a[1] = x;
+
+     Might result in an older value of x stored in a[1] than in a[0].
+     Prevent both the compiler and the CPU from doing this as follows:
+
+	a[0] = ACCESS_ONCE(x);
+	a[1] = ACCESS_ONCE(x);
+
+     In short, ACCESS_ONCE() provides "cache coherence" for accesses from
+     multiple CPUs to a single variable.
+
  (*) The compiler is within its rights to merge successive loads from
      the same variable.  Such merging can cause the compiler to "optimize"
      the following code:
-- 
1.8.1.5