[PATCH -perfboof] memorder: Fix word choice (data dependencies --> address dependencies)

[PATCH -perfboof] memorder: Fix word choice (data dependencies --> address dependencies)

[Akira Yokosawa]

There remain obsolete word choices of "data dependencies" in section
Alpha.

It is load-to-load address dependencies that other archs respect.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
Hi Paul,

I caught them while attempting to add index markers to
address/data/control dependency.

        Thanks, Akira
--
 memorder/memorder.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/memorder/memorder.tex b/memorder/memorder.tex
index 1a4edf8bbb6d..86bb8f41b5f8 100644
--- a/memorder/memorder.tex
+++ b/memorder/memorder.tex
@@ -5403,7 +5403,7 @@ One could place an \co{smp_rmb()} primitive
 between the pointer fetch and dereference in order to force Alpha
 to order the pointer fetch with the later dependent load.
 However, this imposes unneeded overhead on systems (such as \ARM,
-Itanium, PPC, and SPARC) that respect data dependencies on the read side.
+Itanium, PPC, and SPARC) that respect address dependencies on the read side.
 A \co{smp_read_barrier_depends()} primitive was therefore added to the
 Linux kernel to eliminate overhead on these systems, but was removed
 in v5.9 of the Linux kernel in favor of augmenting Alpha's definition
@@ -5428,7 +5428,7 @@ Upon receipt of such an IPI, a CPU would execute a memory-barrier
 instruction, implementing a system-wide memory barrier similar to that
 provided by the Linux kernel's \co{sys_membarrier()} system call.
 Additional logic is required to avoid deadlocks.
-Of course, CPUs that respect data dependencies would define such a barrier
+Of course, CPUs that respect address dependencies would define such a barrier
 to simply be \co{smp_store_release()}.
 However, this approach was deemed by the Linux community
 to impose excessive overhead~\cite{McKenney01f}, and to their point would

base-commit: 8224a12917dd115ead6fce0f785b19a4c7d50f18
-- 
2.25.1

Re: [PATCH -perfboof] memorder: Fix word choice (data dependencies --> address dependencies)

[Paul E. McKenney]

On Mon, Sep 18, 2023 at 10:00:18AM +0900, Akira Yokosawa wrote:
> There remain obsolete word choices of "data dependencies" in section
> Alpha.
> 
> It is load-to-load address dependencies that other archs respect.
> 
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
> Hi Paul,
> 
> I caught them while attempting to add index markers to
> address/data/control dependency.

Good catch, queued and pushed, thank you!!!

							Thanx, Paul

>         Thanks, Akira
> --
>  memorder/memorder.tex | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/memorder/memorder.tex b/memorder/memorder.tex
> index 1a4edf8bbb6d..86bb8f41b5f8 100644
> --- a/memorder/memorder.tex
> +++ b/memorder/memorder.tex
> @@ -5403,7 +5403,7 @@ One could place an \co{smp_rmb()} primitive
>  between the pointer fetch and dereference in order to force Alpha
>  to order the pointer fetch with the later dependent load.
>  However, this imposes unneeded overhead on systems (such as \ARM,
> -Itanium, PPC, and SPARC) that respect data dependencies on the read side.
> +Itanium, PPC, and SPARC) that respect address dependencies on the read side.
>  A \co{smp_read_barrier_depends()} primitive was therefore added to the
>  Linux kernel to eliminate overhead on these systems, but was removed
>  in v5.9 of the Linux kernel in favor of augmenting Alpha's definition
> @@ -5428,7 +5428,7 @@ Upon receipt of such an IPI, a CPU would execute a memory-barrier
>  instruction, implementing a system-wide memory barrier similar to that
>  provided by the Linux kernel's \co{sys_membarrier()} system call.
>  Additional logic is required to avoid deadlocks.
> -Of course, CPUs that respect data dependencies would define such a barrier
> +Of course, CPUs that respect address dependencies would define such a barrier
>  to simply be \co{smp_store_release()}.
>  However, this approach was deemed by the Linux community
>  to impose excessive overhead~\cite{McKenney01f}, and to their point would
> 
> base-commit: 8224a12917dd115ead6fce0f785b19a4c7d50f18
> -- 
> 2.25.1
>