advsync: Fix store-buffering sequence table

Quoted 1 line

From 2845eb208a6e63493997de47293a47ef774a9d49 Mon Sep 17 00:00:00 2001

From: Akira Yokosawa <[email protected]>
Date: Tue, 4 Jul 2017 23:18:30 +0900
Subject: [PATCH] advsync: Fix store-buffering sequence table

Row 6 of the table added in commit 2d5bf8d25a71 ("advsync: Add memory-barriered store-buffering example") needs some context adjustment.

Also tweak horizontal spacing of wide tables for one-column layout. Also add a few words to the footnote giving definition of __atomic_thread_fence().

Signed-off-by Akira Yokosawa <[email protected]>

---
 advsync/memorybarriers.tex | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

advsync/memorybarriers.tex +6 -4

index 4ae3ca8..f26a7c5 100644
@@ -174,7 +174,7 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 
 \begin{table*}
 \small
-\centering
+\centering\OneColumnHSpace{-.1in}
 \begin{tabular}{r||l|l|l||l|l|l}
 	& \multicolumn{3}{c||}{CPU 0} & \multicolumn{3}{c}{CPU 1} \\
 	\cline{2-7}

@@ -318,6 +318,8 @@ ordering and memory barriers work, read on!
 The first stop is
 Figure~\ref{fig:advsync:Memory Ordering: Store-Buffering Litmus Test},
 which has \co{__atomic_thread_fence()} directives\footnote{
+	One of GCC's atomic intrinsics briefly introduced in
+	Section~\ref{sec:toolsoftrade:Atomic Operations (C11)}.
 	Similar to the Linux kernel's \co{smp_mb()} full memory barrier.}
 placed between
 the store and load in both \co{P0()} and \co{P1()}, but is otherwise

@@ -339,7 +341,7 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 
 \begin{table*}
 \small
-\centering
+\centering\OneColumnHSpace{-0.75in}
 \begin{tabular}{r||l|l|l||l|l|l}
 	& \multicolumn{3}{c||}{CPU 0} & \multicolumn{3}{c}{CPU 1} \\
 	\cline{2-7}

@@ -362,8 +364,8 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 	5 & (Finish store) & & \tco{x0==2} &
 		(Finish store) & & \tco{x1==2} \\
 	\hline
-	6 & \tco{r2 = *x1;} (2) & \tco{x0==2} & \tco{x1==0} &
-		\tco{r2 = *x0;} (2) & \tco{x1==2} & \tco{x0==0} \\
+	6 & \tco{r2 = *x1;} (2) & & \tco{x1==2} &
+		\tco{r2 = *x0;} (2) & & \tco{x0==2} \\
 \end{tabular}
 \caption{Memory Ordering: Store-Buffering Sequence of Events}
 \label{tab:advsync:Memory Ordering: Store-Buffering Sequence of Events}

Signature · 1 line

2.7.4

Quoted 9 lines · Akira Yokosawa

Quoted 1 line

From 2845eb208a6e63493997de47293a47ef774a9d49 Mon Sep 17 00:00:00 2001

From: Akira Yokosawa <[email protected]>
Date: Tue, 4 Jul 2017 23:18:30 +0900
Subject: [PATCH] advsync: Fix store-buffering sequence table

Row 6 of the table added in commit 2d5bf8d25a71 ("advsync: Add memory-barriered store-buffering example") needs some context adjustment.

Quoted 5 lines

Also tweak horizontal spacing of wide tables for one-column layout. Also add a few words to the footnote giving definition of __atomic_thread_fence().

Signed-off-by Akira Yokosawa <[email protected]>

Good catches! Queued and pushed. I reworded the footnote a bit, so please let me know if I overdid it.

Thanx, Paul

Quoted 49 lines

---
 advsync/memorybarriers.tex | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

advsync/memorybarriers.tex +6 -4

index 4ae3ca8..f26a7c5 100644
@@ -174,7 +174,7 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 
 \begin{table*}
 \small
-\centering
+\centering\OneColumnHSpace{-.1in}
 \begin{tabular}{r||l|l|l||l|l|l}
 	& \multicolumn{3}{c||}{CPU 0} & \multicolumn{3}{c}{CPU 1} \\
 	\cline{2-7}

@@ -318,6 +318,8 @@ ordering and memory barriers work, read on!
 The first stop is
 Figure~\ref{fig:advsync:Memory Ordering: Store-Buffering Litmus Test},
 which has \co{__atomic_thread_fence()} directives\footnote{
+	One of GCC's atomic intrinsics briefly introduced in
+	Section~\ref{sec:toolsoftrade:Atomic Operations (C11)}.
 	Similar to the Linux kernel's \co{smp_mb()} full memory barrier.}
 placed between
 the store and load in both \co{P0()} and \co{P1()}, but is otherwise

@@ -339,7 +341,7 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 
 \begin{table*}
 \small
-\centering
+\centering\OneColumnHSpace{-0.75in}
 \begin{tabular}{r||l|l|l||l|l|l}
 	& \multicolumn{3}{c||}{CPU 0} & \multicolumn{3}{c}{CPU 1} \\
 	\cline{2-7}

@@ -362,8 +364,8 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 	5 & (Finish store) & & \tco{x0==2} &
 		(Finish store) & & \tco{x1==2} \\
 	\hline
-	6 & \tco{r2 = *x1;} (2) & \tco{x0==2} & \tco{x1==0} &
-		\tco{r2 = *x0;} (2) & \tco{x1==2} & \tco{x0==0} \\
+	6 & \tco{r2 = *x1;} (2) & & \tco{x1==2} &
+		\tco{r2 = *x0;} (2) & & \tco{x0==2} \\
 \end{tabular}
 \caption{Memory Ordering: Store-Buffering Sequence of Events}
 \label{tab:advsync:Memory Ordering: Store-Buffering Sequence of Events}

Signature · 1 line

2.7.4

Quoted 10 lines · Paul E. McKenney

Quoted 9 lines · Akira Yokosawa

Quoted 1 line

From 2845eb208a6e63493997de47293a47ef774a9d49 Mon Sep 17 00:00:00 2001

From: Akira Yokosawa <[email protected]>
Date: Tue, 4 Jul 2017 23:18:30 +0900
Subject: [PATCH] advsync: Fix store-buffering sequence table

Row 6 of the table added in commit 2d5bf8d25a71 ("advsync: Add memory-barriered store-buffering example") needs some context adjustment.

Quoted 8 lines

Quoted 5 lines

Also tweak horizontal spacing of wide tables for one-column layout. Also add a few words to the footnote giving definition of __atomic_thread_fence().

Signed-off-by Akira Yokosawa <[email protected]>

Good catches! Queued and pushed. I reworded the footnote a bit, so please let me know if I overdid it.

After your changes in commit 036372ac2573 ("advsync: Use gcc's C11-like intrinsics to avoid data races"), this footnote seems verbose, doesn't it?

But, I'm not so much a fan of the changes of your commit. It becomes hard to see the relation of lines in litmus tests and rows in the tables. Also, those intrinsics have fairly large overheads.

How about using "volatile" in thread arg declaration such as the following?

---
C C-SB+o-o+o-o
{
}

P0(volatile int *x0, volatile int *x1)

{
	int r2;

	*x0 = 2;
	r2 = *x1;
}

P1(volatile int *x0, volatile int *x1)

{
	int r2;

	*x1 = 2;
	r2 = *x0;
}

exists (1:r2=0 /\ 0:r2=0)
---

If all you need is to prevent memory accesses from being optimized away, they should suffice. But they might be unpopular among kernel community.

I checked the generated C code in cross-compiling mode of litmus7, and the volatile-ness is reflected there.

Thoughts?

Thanks, Akira

Quoted 54 lines

Thanx, Paul

Quoted 49 lines

---
 advsync/memorybarriers.tex | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

advsync/memorybarriers.tex +6 -4

index 4ae3ca8..f26a7c5 100644
@@ -174,7 +174,7 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 
 \begin{table*}
 \small
-\centering
+\centering\OneColumnHSpace{-.1in}
 \begin{tabular}{r||l|l|l||l|l|l}
 	& \multicolumn{3}{c||}{CPU 0} & \multicolumn{3}{c}{CPU 1} \\
 	\cline{2-7}

@@ -318,6 +318,8 @@ ordering and memory barriers work, read on!
 The first stop is
 Figure~\ref{fig:advsync:Memory Ordering: Store-Buffering Litmus Test},
 which has \co{__atomic_thread_fence()} directives\footnote{
+	One of GCC's atomic intrinsics briefly introduced in
+	Section~\ref{sec:toolsoftrade:Atomic Operations (C11)}.
 	Similar to the Linux kernel's \co{smp_mb()} full memory barrier.}
 placed between
 the store and load in both \co{P0()} and \co{P1()}, but is otherwise

@@ -339,7 +341,7 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 
 \begin{table*}
 \small
-\centering
+\centering\OneColumnHSpace{-0.75in}
 \begin{tabular}{r||l|l|l||l|l|l}
 	& \multicolumn{3}{c||}{CPU 0} & \multicolumn{3}{c}{CPU 1} \\
 	\cline{2-7}

@@ -362,8 +364,8 @@ Figure~\ref{fig:advsync:Memory Misordering: Store-Buffering Litmus Test}.
 	5 & (Finish store) & & \tco{x0==2} &
 		(Finish store) & & \tco{x1==2} \\
 	\hline
-	6 & \tco{r2 = *x1;} (2) & \tco{x0==2} & \tco{x1==0} &
-		\tco{r2 = *x0;} (2) & \tco{x1==2} & \tco{x0==0} \\
+	6 & \tco{r2 = *x1;} (2) & & \tco{x1==2} &
+		\tco{r2 = *x0;} (2) & & \tco{x0==2} \\
 \end{tabular}
 \caption{Memory Ordering: Store-Buffering Sequence of Events}
 \label{tab:advsync:Memory Ordering: Store-Buffering Sequence of Events}

Signature · 1 line

2.7.4

Quoted 20 lines · Akira Yokosawa

Quoted 10 lines · Paul E. McKenney

Quoted 9 lines · Akira Yokosawa

Quoted 1 line

From 2845eb208a6e63493997de47293a47ef774a9d49 Mon Sep 17 00:00:00 2001

From: Akira Yokosawa <[email protected]>
Date: Tue, 4 Jul 2017 23:18:30 +0900
Subject: [PATCH] advsync: Fix store-buffering sequence table

Row 6 of the table added in commit 2d5bf8d25a71 ("advsync: Add memory-barriered store-buffering example") needs some context adjustment.

Quoted 8 lines

Quoted 5 lines

Also tweak horizontal spacing of wide tables for one-column layout. Also add a few words to the footnote giving definition of __atomic_thread_fence().

Signed-off-by Akira Yokosawa <[email protected]>

Good catches! Queued and pushed. I reworded the footnote a bit, so please let me know if I overdid it.

Quoted 6 lines

After your changes in commit 036372ac2573 ("advsync: Use gcc's C11-like intrinsics to avoid data races"), this footnote seems verbose, doesn't it?

But, I'm not so much a fan of the changes of your commit. It becomes hard to see the relation of lines in litmus tests and rows in the tables. Also, those intrinsics have fairly large overheads.

They certainly are ugly, no two ways about that! ;-)

Quoted 24 lines

How about using "volatile" in thread arg declaration such as the following?

---
C C-SB+o-o+o-o
{
}

P0(volatile int *x0, volatile int *x1)

{
	int r2;

	*x0 = 2;
	r2 = *x1;
}

P1(volatile int *x0, volatile int *x1)

{
	int r2;

	*x1 = 2;
	r2 = *x0;
}

Quoted 5 lines

exists (1:r2=0 /\ 0:r2=0)
---

If all you need is to prevent memory accesses from being optimized away, they should suffice. But they might be unpopular among kernel community.

To say nothing of their unpopularity among the C11 and C++11 communities!

Quoted 2 lines

I checked the generated C code in cross-compiling mode of litmus7, and the volatile-ness is reflected there.

And it also works just fine without the volatile -- the litmus7 tool does the translation so as to avoid destructive compiler optimizations.

I am checking with the litmus7 people to see if there is any way to map identifiers. Some of the other tools support a "-macros" command-line argument, which would allow mapping from "smp_mb()" to "__atomic_thread_fence(__ATOMIC_SEQ_CST)", but not litmus7.

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

Quoted 74 lines · Paul E. McKenney

Quoted 20 lines · Akira Yokosawa

Quoted 10 lines · Paul E. McKenney

Quoted 9 lines · Akira Yokosawa

Quoted 1 line

From 2845eb208a6e63493997de47293a47ef774a9d49 Mon Sep 17 00:00:00 2001

From: Akira Yokosawa <[email protected]>
Date: Tue, 4 Jul 2017 23:18:30 +0900
Subject: [PATCH] advsync: Fix store-buffering sequence table

Row 6 of the table added in commit 2d5bf8d25a71 ("advsync: Add memory-barriered store-buffering example") needs some context adjustment.

Quoted 8 lines

Quoted 5 lines

Also tweak horizontal spacing of wide tables for one-column layout. Also add a few words to the footnote giving definition of __atomic_thread_fence().

Signed-off-by Akira Yokosawa <[email protected]>

Good catches! Queued and pushed. I reworded the footnote a bit, so please let me know if I overdid it.

Quoted 6 lines

After your changes in commit 036372ac2573 ("advsync: Use gcc's C11-like intrinsics to avoid data races"), this footnote seems verbose, doesn't it?

But, I'm not so much a fan of the changes of your commit. It becomes hard to see the relation of lines in litmus tests and rows in the tables. Also, those intrinsics have fairly large overheads.

They certainly are ugly, no two ways about that! ;-)

Quoted 24 lines

How about using "volatile" in thread arg declaration such as the following?

---
C C-SB+o-o+o-o
{
}

P0(volatile int *x0, volatile int *x1)

{
	int r2;

	*x0 = 2;
	r2 = *x1;
}

P1(volatile int *x0, volatile int *x1)

{
	int r2;

	*x1 = 2;
	r2 = *x0;
}

Quoted 5 lines

exists (1:r2=0 /\ 0:r2=0)
---

If all you need is to prevent memory accesses from being optimized away, they should suffice. But they might be unpopular among kernel community.

To say nothing of their unpopularity among the C11 and C++11 communities!

Quoted 2 lines

I checked the generated C code in cross-compiling mode of litmus7, and the volatile-ness is reflected there.

And it also works just fine without the volatile -- the litmus7 tool does the translation so as to avoid destructive compiler optimizations.

I am checking with the litmus7 people to see if there is any way to map identifiers. Some of the other tools support a "-macros" command-line argument, which would allow mapping from "smp_mb()" to "__atomic_thread_fence(__ATOMIC_SEQ_CST)", but not litmus7.

Quoted 2 lines

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

Quoted 55 lines · Paul E. McKenney

Quoted 54 lines · Paul E. McKenney

Quoted 20 lines · Akira Yokosawa

Quoted 10 lines · Paul E. McKenney

Quoted 9 lines · Akira Yokosawa

Quoted 1 line

From 2845eb208a6e63493997de47293a47ef774a9d49 Mon Sep 17 00:00:00 2001

From: Akira Yokosawa <[email protected]>
Date: Tue, 4 Jul 2017 23:18:30 +0900
Subject: [PATCH] advsync: Fix store-buffering sequence table

Row 6 of the table added in commit 2d5bf8d25a71 ("advsync: Add memory-barriered store-buffering example") needs some context adjustment.

Quoted 8 lines

Quoted 5 lines

Also tweak horizontal spacing of wide tables for one-column layout. Also add a few words to the footnote giving definition of __atomic_thread_fence().

Signed-off-by Akira Yokosawa <[email protected]>

Good catches! Queued and pushed. I reworded the footnote a bit, so please let me know if I overdid it.

Quoted 6 lines

After your changes in commit 036372ac2573 ("advsync: Use gcc's C11-like intrinsics to avoid data races"), this footnote seems verbose, doesn't it?

But, I'm not so much a fan of the changes of your commit. It becomes hard to see the relation of lines in litmus tests and rows in the tables. Also, those intrinsics have fairly large overheads.

They certainly are ugly, no two ways about that! ;-)

Quoted 24 lines

How about using "volatile" in thread arg declaration such as the following?

---
C C-SB+o-o+o-o
{
}

P0(volatile int *x0, volatile int *x1)

{
	int r2;

	*x0 = 2;
	r2 = *x1;
}

P1(volatile int *x0, volatile int *x1)

{
	int r2;

	*x1 = 2;
	r2 = *x0;
}

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

exists (1:r2=0 /\ 0:r2=0)
---

If all you need is to prevent memory accesses from being optimized away, they should suffice. But they might be unpopular among kernel community.

To say nothing of their unpopularity among the C11 and C++11 communities!

Quoted 15 lines

Quoted 14 lines

Quoted 3 lines

I checked the generated C code in cross-compiling mode of litmus7, and the volatile-ness is reflected there.

And it also works just fine without the volatile -- the litmus7 tool does the translation so as to avoid destructive compiler optimizations.

I am checking with the litmus7 people to see if there is any way to map identifiers. Some of the other tools support a "-macros" command-line argument, which would allow mapping from "smp_mb()" to "__atomic_thread_fence(__ATOMIC_SEQ_CST)", but not litmus7.

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

Quoted 3 lines

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

And it turns out that the contents of a second "{}" in a litmus7 test is pulled directly into the output code, so an easy change. ;-)

Thanx, Paul

On 2017/07/05 10:32:49 -0700, Paul E. McKenney wrote:

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

Quoted 2 lines

And it turns out that the contents of a second "{}" in a litmus7 test is pulled directly into the output code, so an easy change. ;-)

Good news!

So __atomic_thread_fence() will also be replaced with smp_mb() in the litmus tests? That will reduce the width of the tables and eliminate the need for the hspece adjustments in one-column layout.

Quoted 1 line · Akira Yokosawa

On 2017/07/05 10:32:49 -0700, Paul E. McKenney wrote:

[ . . . ]

Quoted 12 lines

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

And it turns out that the contents of a second "{}" in a litmus7 test is pulled directly into the output code, so an easy change. ;-)

Good news!

Quoted 3 lines

So __atomic_thread_fence() will also be replaced with smp_mb() in the litmus tests? That will reduce the width of the tables and eliminate the need for the hspece adjustments in one-column layout.

Oops, I forgot to push! Done now.

And yes, there is now smp_mb() in the litmus tests and the tables.

Thanx, Paul

Quoted 21 lines · Paul E. McKenney

Quoted 1 line · Akira Yokosawa

On 2017/07/05 10:32:49 -0700, Paul E. McKenney wrote:

[ . . . ]

Quoted 15 lines

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

And it turns out that the contents of a second "{}" in a litmus7 test is pulled directly into the output code, so an easy change. ;-)

Good news!

So __atomic_thread_fence() will also be replaced with smp_mb() in the litmus tests? That will reduce the width of the tables and eliminate the need for the hspece adjustments in one-column layout.

Quoted 3 lines

Oops, I forgot to push! Done now.

And yes, there is now smp_mb() in the litmus tests and the tables.

I'll take a look later.
As I mentioned earlier, __atomic_load_n() and __atomic_store_n() seem to have fairly large overheads (on x86). You might want to see the changes in the resulting statistics and reflect them in the text.

Quoted 23 lines · Akira Yokosawa

Quoted 22 lines · Paul E. McKenney

Quoted 2 lines · Akira Yokosawa

On 2017/07/05 10:32:49 -0700, Paul E. McKenney wrote:

[ . . . ]

Quoted 15 lines

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

And it turns out that the contents of a second "{}" in a litmus7 test is pulled directly into the output code, so an easy change. ;-)

Good news!

So __atomic_thread_fence() will also be replaced with smp_mb() in the litmus tests? That will reduce the width of the tables and eliminate the need for the hspece adjustments in one-column layout.

Quoted 8 lines

Quoted 3 lines

Oops, I forgot to push! Done now.

And yes, there is now smp_mb() in the litmus tests and the tables.

I'll take a look later.
As I mentioned earlier, __atomic_load_n() and __atomic_store_n() seem to have fairly large overheads (on x86). You might want to see the changes in the resulting statistics and reflect them in the text.

I am getting a fair amount of variance on the results, and thus a fair amount of overlap in the number of times each scenario shows up. Perhaps I should say that and also state that different hardware will likely get different results?

Thanx, Paul

Quoted 21 lines · Paul E. McKenney

Quoted 1 line · Akira Yokosawa

On 2017/07/05 10:32:49 -0700, Paul E. McKenney wrote:

[ . . . ]

Quoted 15 lines

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

And it turns out that the contents of a second "{}" in a litmus7 test is pulled directly into the output code, so an easy change. ;-)

Good news!

So __atomic_thread_fence() will also be replaced with smp_mb() in the litmus tests? That will reduce the width of the tables and eliminate the need for the hspece adjustments in one-column layout.

Quoted 3 lines

Oops, I forgot to push! Done now.

And yes, there is now smp_mb() in the litmus tests and the tables.

I'll take a look later.
As I mentioned earlier, __atomic_load_n() and __atomic_store_n() seem to have fairly large overheads (on x86). You might want to see the changes in the resulting statistics and reflect them in the text.

Thanks, Akira

Quoted 4 lines

Thanx, Paul

Quoted 22 lines · Akira Yokosawa

Quoted 21 lines · Paul E. McKenney

Quoted 1 line · Akira Yokosawa

On 2017/07/05 10:32:49 -0700, Paul E. McKenney wrote:

[ . . . ]

Quoted 15 lines

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

So I cannot go with "volatile", but let's see if I can do something better than the gcc intrinsics.

And if the litmus7 guys don't have anything for me, I can always write a script to do the conversions. So either way, we will have kernel-style notation at some point. ;-)

And it turns out that the contents of a second "{}" in a litmus7 test is pulled directly into the output code, so an easy change. ;-)

Good news!

So __atomic_thread_fence() will also be replaced with smp_mb() in the litmus tests? That will reduce the width of the tables and eliminate the need for the hspece adjustments in one-column layout.

Quoted 8 lines

Quoted 3 lines

Oops, I forgot to push! Done now.

And yes, there is now smp_mb() in the litmus tests and the tables.

I'll take a look later.
As I mentioned earlier, __atomic_load_n() and __atomic_store_n() seem to have fairly large overheads (on x86). You might want to see the changes in the resulting statistics and reflect them in the text.

Hi Paul,

The definition of READ_ONCE() and WRITE_ONCE() given in the updated litmus tests is inconsistent with kernel API. They are accepting pointers such as x0 and x1.

In the article at LWN (https://lwn.net/Articles/720550/), litmus tests use the same definition as kernel API. They take the value expression such as *x0 and *x1.

My preference is to accept pointers as arguments as is the way in C functions, but the kernel community have chosen otherwise. We should be consist here.

So the definition should be:

---
#define READ_ONCE(x) __atomic_load_n(&(x), __ATOMIC_RELAXED) #define WRITE_ONCE(x, v) __atomic_store_n(&(x), (v), __ATOMIC_RELAXED) #define smp_mb() __atomic_thread_fence(__ATOMIC_SEQ_CST)
---

Or am I misreading?