* [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 19:57 ` Arnd Bergmann
2019-11-08 17:01 ` [PATCH 02/13] READ_ONCE: Undefine internal __READ_ONCE_SIZE macro after use Will Deacon
` (12 subsequent siblings)
13 siblings, 1 reply; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
In preparation for allowing architectures to define their own
implementation of the 'READ_ONCE()' macro, move the generic
'{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h'
and into a new 'rwonce.h' header under 'asm-generic'.
Signed-off-by: Will Deacon <will@kernel.org>
---
include/asm-generic/Kbuild | 1 +
include/asm-generic/rwonce.h | 110 +++++++++++++++++++++++++++
include/linux/compiler.h | 114 +---------------------------
include/linux/compiler_attributes.h | 12 +++
4 files changed, 125 insertions(+), 112 deletions(-)
create mode 100644 include/asm-generic/rwonce.h
diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
index adff14fcb8e4..2a7a1e94d4cb 100644
--- a/include/asm-generic/Kbuild
+++ b/include/asm-generic/Kbuild
@@ -4,4 +4,5 @@
# (This file is not included when SRCARCH=um since UML borrows several
# asm headers from the host architecutre.)
+mandatory-y += rwonce.h
mandatory-y += simd.h
diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
new file mode 100644
index 000000000000..d189455ae038
--- /dev/null
+++ b/include/asm-generic/rwonce.h
@@ -0,0 +1,110 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Prevent the compiler from merging or refetching reads or writes. The
+ * compiler is also forbidden from reordering successive instances of
+ * READ_ONCE and WRITE_ONCE, but only when the compiler is aware of some
+ * particular ordering. One way to make the compiler aware of ordering is to
+ * put the two invocations of READ_ONCE or WRITE_ONCE in different C
+ * statements.
+ *
+ * These two macros will also work on aggregate data types like structs or
+ * unions. If the size of the accessed data type exceeds the word size of
+ * the machine (e.g., 32 bits or 64 bits) READ_ONCE() and WRITE_ONCE() will
+ * fall back to memcpy(). There's at least two memcpy()s: one for the
+ * __builtin_memcpy() and then one for the macro doing the copy of variable
+ * - '__u' allocated on the stack.
+ *
+ * Their two major use cases are: (1) Mediating communication between
+ * process-level code and irq/NMI handlers, all running on the same CPU,
+ * and (2) Ensuring that the compiler does not fold, spindle, or otherwise
+ * mutilate accesses that either do not require ordering or that interact
+ * with an explicit memory barrier or atomic instruction that provides the
+ * required ordering.
+ */
+#ifndef __ASM_GENERIC_RWONCE_H
+#define __ASM_GENERIC_RWONCE_H
+
+#ifndef __ASSEMBLY__
+
+#include <linux/compiler_attributes.h>
+#include <linux/kasan-checks.h>
+
+#include <uapi/linux/types.h>
+
+#include <asm/barrier.h>
+
+#define __READ_ONCE_SIZE \
+({ \
+ switch (size) { \
+ case 1: *(__u8 *)res = *(volatile __u8 *)p; break; \
+ case 2: *(__u16 *)res = *(volatile __u16 *)p; break; \
+ case 4: *(__u32 *)res = *(volatile __u32 *)p; break; \
+ case 8: *(__u64 *)res = *(volatile __u64 *)p; break; \
+ default: \
+ barrier(); \
+ __builtin_memcpy((void *)res, (const void *)p, size); \
+ barrier(); \
+ } \
+})
+
+static __always_inline
+void __read_once_size(const volatile void *p, void *res, int size)
+{
+ __READ_ONCE_SIZE;
+}
+
+static __no_kasan_or_inline
+void __read_once_size_nocheck(const volatile void *p, void *res, int size)
+{
+ __READ_ONCE_SIZE;
+}
+
+static __always_inline void __write_once_size(volatile void *p, void *res, int size)
+{
+ switch (size) {
+ case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
+ case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
+ case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
+ case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
+ default:
+ barrier();
+ __builtin_memcpy((void *)p, (const void *)res, size);
+ barrier();
+ }
+}
+
+#define __READ_ONCE(x, check) \
+({ \
+ union { typeof(x) __val; char __c[1]; } __u; \
+ if (check) \
+ __read_once_size(&(x), __u.__c, sizeof(x)); \
+ else \
+ __read_once_size_nocheck(&(x), __u.__c, sizeof(x)); \
+ smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
+ __u.__val; \
+})
+#define READ_ONCE(x) __READ_ONCE(x, 1)
+
+/*
+ * Use READ_ONCE_NOCHECK() instead of READ_ONCE() if you need
+ * to hide memory access from KASAN.
+ */
+#define READ_ONCE_NOCHECK(x) __READ_ONCE(x, 0)
+
+static __no_kasan_or_inline
+unsigned long read_word_at_a_time(const void *addr)
+{
+ kasan_check_read(addr, 1);
+ return *(unsigned long *)addr;
+}
+
+#define WRITE_ONCE(x, val) \
+({ \
+ union { typeof(x) __val; char __c[1]; } __u = \
+ { .__val = (__force typeof(x)) (val) }; \
+ __write_once_size(&(x), __u.__c, sizeof(x)); \
+ __u.__val; \
+})
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_GENERIC_RWONCE_H */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 5e88e7e33abe..6de09d2f42ad 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -177,118 +177,6 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
#endif
-#include <uapi/linux/types.h>
-
-#define __READ_ONCE_SIZE \
-({ \
- switch (size) { \
- case 1: *(__u8 *)res = *(volatile __u8 *)p; break; \
- case 2: *(__u16 *)res = *(volatile __u16 *)p; break; \
- case 4: *(__u32 *)res = *(volatile __u32 *)p; break; \
- case 8: *(__u64 *)res = *(volatile __u64 *)p; break; \
- default: \
- barrier(); \
- __builtin_memcpy((void *)res, (const void *)p, size); \
- barrier(); \
- } \
-})
-
-static __always_inline
-void __read_once_size(const volatile void *p, void *res, int size)
-{
- __READ_ONCE_SIZE;
-}
-
-#ifdef CONFIG_KASAN
-/*
- * We can't declare function 'inline' because __no_sanitize_address confilcts
- * with inlining. Attempt to inline it may cause a build failure.
- * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
- * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
- */
-# define __no_kasan_or_inline __no_sanitize_address notrace __maybe_unused
-#else
-# define __no_kasan_or_inline __always_inline
-#endif
-
-static __no_kasan_or_inline
-void __read_once_size_nocheck(const volatile void *p, void *res, int size)
-{
- __READ_ONCE_SIZE;
-}
-
-static __always_inline void __write_once_size(volatile void *p, void *res, int size)
-{
- switch (size) {
- case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
- case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
- case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
- case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
- default:
- barrier();
- __builtin_memcpy((void *)p, (const void *)res, size);
- barrier();
- }
-}
-
-/*
- * Prevent the compiler from merging or refetching reads or writes. The
- * compiler is also forbidden from reordering successive instances of
- * READ_ONCE and WRITE_ONCE, but only when the compiler is aware of some
- * particular ordering. One way to make the compiler aware of ordering is to
- * put the two invocations of READ_ONCE or WRITE_ONCE in different C
- * statements.
- *
- * These two macros will also work on aggregate data types like structs or
- * unions. If the size of the accessed data type exceeds the word size of
- * the machine (e.g., 32 bits or 64 bits) READ_ONCE() and WRITE_ONCE() will
- * fall back to memcpy(). There's at least two memcpy()s: one for the
- * __builtin_memcpy() and then one for the macro doing the copy of variable
- * - '__u' allocated on the stack.
- *
- * Their two major use cases are: (1) Mediating communication between
- * process-level code and irq/NMI handlers, all running on the same CPU,
- * and (2) Ensuring that the compiler does not fold, spindle, or otherwise
- * mutilate accesses that either do not require ordering or that interact
- * with an explicit memory barrier or atomic instruction that provides the
- * required ordering.
- */
-#include <asm/barrier.h>
-#include <linux/kasan-checks.h>
-
-#define __READ_ONCE(x, check) \
-({ \
- union { typeof(x) __val; char __c[1]; } __u; \
- if (check) \
- __read_once_size(&(x), __u.__c, sizeof(x)); \
- else \
- __read_once_size_nocheck(&(x), __u.__c, sizeof(x)); \
- smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
- __u.__val; \
-})
-#define READ_ONCE(x) __READ_ONCE(x, 1)
-
-/*
- * Use READ_ONCE_NOCHECK() instead of READ_ONCE() if you need
- * to hide memory access from KASAN.
- */
-#define READ_ONCE_NOCHECK(x) __READ_ONCE(x, 0)
-
-static __no_kasan_or_inline
-unsigned long read_word_at_a_time(const void *addr)
-{
- kasan_check_read(addr, 1);
- return *(unsigned long *)addr;
-}
-
-#define WRITE_ONCE(x, val) \
-({ \
- union { typeof(x) __val; char __c[1]; } __u = \
- { .__val = (__force typeof(x)) (val) }; \
- __write_once_size(&(x), __u.__c, sizeof(x)); \
- __u.__val; \
-})
-
#endif /* __KERNEL__ */
/*
@@ -356,4 +244,6 @@ static inline void *offset_to_ptr(const int *off)
/* &a[0] degrades to a pointer: a different type from an array */
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
+#include <asm/rwonce.h>
+
#endif /* __LINUX_COMPILER_H */
diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
index cdf016596659..7cb92286de9f 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -270,4 +270,16 @@
*/
#define __weak __attribute__((__weak__))
+#ifdef CONFIG_KASAN
+/*
+ * We can't declare function 'inline' because __no_sanitize_address confilcts
+ * with inlining. Attempt to inline it may cause a build failure.
+ * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
+ * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
+ */
+# define __no_kasan_or_inline __no_sanitize_address notrace __maybe_unused
+#else
+# define __no_kasan_or_inline __always_inline
+#endif
+
#endif /* __LINUX_COMPILER_ATTRIBUTES_H */
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* Re: [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
2019-11-08 17:01 ` [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h Will Deacon
@ 2019-11-08 19:57 ` Arnd Bergmann
2019-11-11 8:10 ` Christian Borntraeger
0 siblings, 1 reply; 35+ messages in thread
From: Arnd Bergmann @ 2019-11-08 19:57 UTC (permalink / raw)
To: Will Deacon
Cc: linux-kernel, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Joe Perches, Boqun Feng, alpha, virtualization,
Christian Borntraeger
On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will@kernel.org> wrote:
>
> In preparation for allowing architectures to define their own
> implementation of the 'READ_ONCE()' macro, move the generic
> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h'
> and into a new 'rwonce.h' header under 'asm-generic'.
Adding Christian Bornträger to Cc, he originally added the
READ_ONCE()/WRITE_ONCE()
code.
I wonder if it would be appropriate now to revert back to a much simpler version
of these helpers for any modern compiler. As I understand, only gcc-4.6 and
gcc4.7 actually need the song-and-dance version with the union and switch/case,
while for others, we can might be able back to a macro doing a volatile access.
Arnd
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
2019-11-08 19:57 ` Arnd Bergmann
@ 2019-11-11 8:10 ` Christian Borntraeger
2019-11-11 9:32 ` Arnd Bergmann
0 siblings, 1 reply; 35+ messages in thread
From: Christian Borntraeger @ 2019-11-11 8:10 UTC (permalink / raw)
To: Arnd Bergmann, Will Deacon
Cc: linux-kernel, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Joe Perches, Boqun Feng, alpha, virtualization
On 08.11.19 20:57, Arnd Bergmann wrote:
> On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will@kernel.org> wrote:
>>
>> In preparation for allowing architectures to define their own
>> implementation of the 'READ_ONCE()' macro, move the generic
>> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h'
>> and into a new 'rwonce.h' header under 'asm-generic'.
>
> Adding Christian Bornträger to Cc, he originally added the
> READ_ONCE()/WRITE_ONCE()
> code.
>
> I wonder if it would be appropriate now to revert back to a much simpler version
> of these helpers for any modern compiler. As I understand, only gcc-4.6 and
> gcc4.7 actually need the song-and-dance version with the union and switch/case,
> while for others, we can might be able back to a macro doing a volatile access.
As far as I know this particular issue with volatile access on aggregate types
was fixed in gcc 4.8. On the other hand we know that the current construct will
work on all compilers. Not so sure about the orignal ACCESS_ONCE implementation.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
2019-11-11 8:10 ` Christian Borntraeger
@ 2019-11-11 9:32 ` Arnd Bergmann
2019-11-12 11:36 ` Will Deacon
0 siblings, 1 reply; 35+ messages in thread
From: Arnd Bergmann @ 2019-11-11 9:32 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Will Deacon, linux-kernel, Yunjae Lee, SeongJae Park,
Paul E. McKenney, Josh Triplett, Matt Turner, Ivan Kokshaysky,
Richard Henderson, Peter Zijlstra, Alan Stern, Michael Ellerman,
Michael S. Tsirkin, Jason Wang, Joe Perches, Boqun Feng, alpha,
virtualization
On Mon, Nov 11, 2019 at 9:10 AM Christian Borntraeger
<borntraeger@de.ibm.com> wrote:
> On 08.11.19 20:57, Arnd Bergmann wrote:
> > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will@kernel.org> wrote:
> >>
> >> In preparation for allowing architectures to define their own
> >> implementation of the 'READ_ONCE()' macro, move the generic
> >> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h'
> >> and into a new 'rwonce.h' header under 'asm-generic'.
> >
> > Adding Christian Bornträger to Cc, he originally added the
> > READ_ONCE()/WRITE_ONCE()
> > code.
> >
> > I wonder if it would be appropriate now to revert back to a much simpler version
> > of these helpers for any modern compiler. As I understand, only gcc-4.6 and
> > gcc4.7 actually need the song-and-dance version with the union and switch/case,
> > while for others, we can might be able back to a macro doing a volatile access.
>
> As far as I know this particular issue with volatile access on aggregate types
> was fixed in gcc 4.8. On the other hand we know that the current construct will
> work on all compilers. Not so sure about the orignal ACCESS_ONCE implementation.
I've seen problems with clang on the current version, leading to unnecessary
temporaries being spilled to the stack in some cases, so I think it would still
help to simplify it.
We probably don't want the exact ACCESS_ONCE() implementation back
that existed before, but rather something that implements the stricter
READ_ONCE() and WRITE_ONCE(). I'd probably also want to avoid the
__builtin_memcpy() exception for odd-sized accesses and instead have
a separate way to do those.
Arnd
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
2019-11-11 9:32 ` Arnd Bergmann
@ 2019-11-12 11:36 ` Will Deacon
0 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-12 11:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Christian Borntraeger, linux-kernel, Yunjae Lee, SeongJae Park,
Paul E. McKenney, Josh Triplett, Matt Turner, Ivan Kokshaysky,
Richard Henderson, Peter Zijlstra, Alan Stern, Michael Ellerman,
Michael S. Tsirkin, Jason Wang, Joe Perches, Boqun Feng, alpha,
virtualization
On Mon, Nov 11, 2019 at 10:32:46AM +0100, Arnd Bergmann wrote:
> On Mon, Nov 11, 2019 at 9:10 AM Christian Borntraeger
> <borntraeger@de.ibm.com> wrote:
> > On 08.11.19 20:57, Arnd Bergmann wrote:
> > > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will@kernel.org> wrote:
> > >>
> > >> In preparation for allowing architectures to define their own
> > >> implementation of the 'READ_ONCE()' macro, move the generic
> > >> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h'
> > >> and into a new 'rwonce.h' header under 'asm-generic'.
> > >
> > > Adding Christian Bornträger to Cc, he originally added the
> > > READ_ONCE()/WRITE_ONCE()
> > > code.
> > >
> > > I wonder if it would be appropriate now to revert back to a much simpler version
> > > of these helpers for any modern compiler. As I understand, only gcc-4.6 and
> > > gcc4.7 actually need the song-and-dance version with the union and switch/case,
> > > while for others, we can might be able back to a macro doing a volatile access.
> >
> > As far as I know this particular issue with volatile access on aggregate types
> > was fixed in gcc 4.8. On the other hand we know that the current construct will
> > work on all compilers. Not so sure about the orignal ACCESS_ONCE implementation.
>
> I've seen problems with clang on the current version, leading to unnecessary
> temporaries being spilled to the stack in some cases, so I think it would still
> help to simplify it.
>
> We probably don't want the exact ACCESS_ONCE() implementation back
> that existed before, but rather something that implements the stricter
> READ_ONCE() and WRITE_ONCE(). I'd probably also want to avoid the
> __builtin_memcpy() exception for odd-sized accesses and instead have
> a separate way to do those.
If you have a patch, I'm happy to carry it at the end of the series to
avoid conflicts. It's not completely clear to me what you're after, so if
you need me to adjust anything here then please shout!
Will
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 02/13] READ_ONCE: Undefine internal __READ_ONCE_SIZE macro after use
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
2019-11-08 17:01 ` [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 03/13] READ_ONCE: Allow __READ_ONCE_SIZE cases to be overridden by the architecture Will Deacon
` (11 subsequent siblings)
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
The '__READ_ONCE_SIZE()' macro is only used as part of building
'READ_ONCE()', so undefine it once we don't need it anymore.
Signed-off-by: Will Deacon <will@kernel.org>
---
include/asm-generic/rwonce.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index d189455ae038..abf326634ecd 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -59,6 +59,8 @@ void __read_once_size_nocheck(const volatile void *p, void *res, int size)
__READ_ONCE_SIZE;
}
+#undef __READ_ONCE_SIZE
+
static __always_inline void __write_once_size(volatile void *p, void *res, int size)
{
switch (size) {
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 03/13] READ_ONCE: Allow __READ_ONCE_SIZE cases to be overridden by the architecture
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
2019-11-08 17:01 ` [PATCH 01/13] compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h Will Deacon
2019-11-08 17:01 ` [PATCH 02/13] READ_ONCE: Undefine internal __READ_ONCE_SIZE macro after use Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 04/13] vhost: Remove redundant use of read_barrier_depends() barrier Will Deacon
` (10 subsequent siblings)
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
The meat and potatoes of 'READ_ONCE()' is defined by the
'__READ_ONCE_SIZE()' macro, which uses volatile casts in an attempt to
avoid tearing of byte, halfword, word and double-word accesses. Allow
this to be overridden by the architecture code in the case that things
like memory barriers are also required.
Signed-off-by: Will Deacon <will@kernel.org>
---
include/asm-generic/rwonce.h | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index abf326634ecd..2c2ac0948c94 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -33,13 +33,29 @@
#include <asm/barrier.h>
+#ifndef __read_once_size_1
+#define __read_once_size_1(p) (*(volatile __u8 *)(p))
+#endif
+
+#ifndef __read_once_size_2
+#define __read_once_size_2(p) (*(volatile __u16 *)(p))
+#endif
+
+#ifndef __read_once_size_4
+#define __read_once_size_4(p) (*(volatile __u32 *)(p))
+#endif
+
+#ifndef __read_once_size_8
+#define __read_once_size_8(p) (*(volatile __u64 *)(p))
+#endif
+
#define __READ_ONCE_SIZE \
({ \
switch (size) { \
- case 1: *(__u8 *)res = *(volatile __u8 *)p; break; \
- case 2: *(__u16 *)res = *(volatile __u16 *)p; break; \
- case 4: *(__u32 *)res = *(volatile __u32 *)p; break; \
- case 8: *(__u64 *)res = *(volatile __u64 *)p; break; \
+ case 1: *(__u8 *)res = __read_once_size_1(p); break; \
+ case 2: *(__u16 *)res = __read_once_size_2(p); break; \
+ case 4: *(__u32 *)res = __read_once_size_4(p); break; \
+ case 8: *(__u64 *)res = __read_once_size_8(p); break; \
default: \
barrier(); \
__builtin_memcpy((void *)res, (const void *)p, size); \
@@ -59,6 +75,10 @@ void __read_once_size_nocheck(const volatile void *p, void *res, int size)
__READ_ONCE_SIZE;
}
+#undef __read_once_size_1
+#undef __read_once_size_2
+#undef __read_once_size_4
+#undef __read_once_size_8
#undef __READ_ONCE_SIZE
static __always_inline void __write_once_size(volatile void *p, void *res, int size)
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 04/13] vhost: Remove redundant use of read_barrier_depends() barrier
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (2 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 03/13] READ_ONCE: Allow __READ_ONCE_SIZE cases to be overridden by the architecture Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 05/13] alpha: Override READ_ONCE() with barriered implementation Will Deacon
` (9 subsequent siblings)
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
Since commit 76ebbe78f739 ("locking/barriers: Add implicit
smp_read_barrier_depends() to READ_ONCE()"), there is no need to use
'smp_read_barrier_depends()' outside of the Alpha architecture code.
Unfortunately, there is precisely >one< user in the vhost code, and
there isn't an obvious 'READ_ONCE()' access making the barrier
redundant. However, on closer inspection (thanks, Jason), it appears
that vring synchronisation between the producer and consumer occurs via
the 'avail_idx' field, which is followed up by an 'rmb()' in
'vhost_get_vq_desc()', making the 'read_barrier_depends()' redundant on
Alpha.
Jason says:
| I'm also confused about the barrier here, basically in driver side
| we did:
|
| 1) allocate pages
| 2) store pages in indirect->addr
| 3) smp_wmb()
| 4) increase the avail idx (somehow a tail pointer of vring)
|
| in vhost we did:
|
| 1) read avail idx
| 2) smp_rmb()
| 3) read indirect->addr
| 4) read from indirect->addr
|
| It looks to me even the data dependency barrier is not necessary
| since we have rmb() which is sufficient for us to the correct
| indirect->addr and driver are not expected to do any writing to
| indirect->addr after avail idx is increased
Remove the redundant barrier invocation.
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
drivers/vhost/vhost.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 36ca2cf419bf..865bc91b783c 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2128,11 +2128,6 @@ static int get_indirect(struct vhost_virtqueue *vq,
return ret;
}
iov_iter_init(&from, READ, vq->indirect, ret, len);
-
- /* We will use the result as an address to read from, so most
- * architectures only need a compiler barrier here. */
- read_barrier_depends();
-
count = len / sizeof desc;
/* Buffers are chained via a 16 bit next field, so
* we can have at most 2^16 of these. */
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 05/13] alpha: Override READ_ONCE() with barriered implementation
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (3 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 04/13] vhost: Remove redundant use of read_barrier_depends() barrier Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 06/13] READ_ONCE: Remove smp_read_barrier_depends() invocation Will Deacon
` (8 subsequent siblings)
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
Rather then relying on the core code to use 'smp_read_barrier_depends()'
as part of the 'READ_ONCE()' definition, instead override 'READ_ONCE()'
in the Alpha code so that it is treated the same way as
'smp_load_acquire()'.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/alpha/include/asm/barrier.h | 61 ++++----------------------------
arch/alpha/include/asm/rwonce.h | 22 ++++++++++++
2 files changed, 29 insertions(+), 54 deletions(-)
create mode 100644 arch/alpha/include/asm/rwonce.h
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index 92ec486a4f9e..1f6abe2d1392 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -2,64 +2,17 @@
#ifndef __BARRIER_H
#define __BARRIER_H
-#include <asm/compiler.h>
-
#define mb() __asm__ __volatile__("mb": : :"memory")
#define rmb() __asm__ __volatile__("mb": : :"memory")
#define wmb() __asm__ __volatile__("wmb": : :"memory")
-/**
- * read_barrier_depends - Flush all pending reads that subsequents reads
- * depend on.
- *
- * No data-dependent reads from memory-like regions are ever reordered
- * over this barrier. All reads preceding this primitive are guaranteed
- * to access memory (but not necessarily other CPUs' caches) before any
- * reads following this primitive that depend on the data return by
- * any of the preceding reads. This primitive is much lighter weight than
- * rmb() on most CPUs, and is never heavier weight than is
- * rmb().
- *
- * These ordering constraints are respected by both the local CPU
- * and the compiler.
- *
- * Ordering is not guaranteed by anything other than these primitives,
- * not even by data dependencies. See the documentation for
- * memory_barrier() for examples and URLs to more information.
- *
- * For example, the following code would force ordering (the initial
- * value of "a" is zero, "b" is one, and "p" is "&a"):
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * b = 2;
- * memory_barrier();
- * p = &b; q = p;
- * read_barrier_depends();
- * d = *q;
- * </programlisting>
- *
- * because the read of "*q" depends on the read of "p" and these
- * two reads are separated by a read_barrier_depends(). However,
- * the following code, with the same initial values for "a" and "b":
- *
- * <programlisting>
- * CPU 0 CPU 1
- *
- * a = 2;
- * memory_barrier();
- * b = 3; y = b;
- * read_barrier_depends();
- * x = a;
- * </programlisting>
- *
- * does not enforce ordering, since there is no data dependency between
- * the read of "a" and the read of "b". Therefore, on some CPUs, such
- * as Alpha, "y" could be set to 3 and "x" to 0. Use rmb()
- * in cases like this where there are no data dependencies.
- */
-#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
+#define __smp_load_acquire(p) \
+({ \
+ typeof(*p) ___p1 = (*(volatile typeof(*p) *)(p)); \
+ compiletime_assert_atomic_type(*p); \
+ mb(); \
+ ___p1; \
+})
#ifdef CONFIG_SMP
#define __ASM_SMP_MB "\tmb\n"
diff --git a/arch/alpha/include/asm/rwonce.h b/arch/alpha/include/asm/rwonce.h
new file mode 100644
index 000000000000..ef5601352b55
--- /dev/null
+++ b/arch/alpha/include/asm/rwonce.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Google LLC.
+ */
+#ifndef __ASM_RWONCE_H
+#define __ASM_RWONCE_H
+
+#include <asm/barrier.h>
+
+/*
+ * Alpha is apparently daft enough to reorder address-dependent loads
+ * on some CPU implementations. Knock some common sense into it with
+ * a memory barrier in READ_ONCE().
+ */
+#define __read_once_size_1(p) __smp_load_acquire((u8 *)(p))
+#define __read_once_size_2(p) __smp_load_acquire((u16 *)(p))
+#define __read_once_size_4(p) __smp_load_acquire((u32 *)(p))
+#define __read_once_size_8(p) __smp_load_acquire((u64 *)(p))
+
+#include <asm-generic/rwonce.h>
+
+#endif /* __ASM_RWONCE_H */
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 06/13] READ_ONCE: Remove smp_read_barrier_depends() invocation
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (4 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 05/13] alpha: Override READ_ONCE() with barriered implementation Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 07/13] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb() Will Deacon
` (7 subsequent siblings)
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
Alpha overrides '__read_once_size_n()' directly, so there's no need to
use 'smp_read_barrier_depends()' in the core code.
Signed-off-by: Will Deacon <will@kernel.org>
---
include/asm-generic/rwonce.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index 2c2ac0948c94..2e3289268a89 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -102,7 +102,6 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
__read_once_size(&(x), __u.__c, sizeof(x)); \
else \
__read_once_size_nocheck(&(x), __u.__c, sizeof(x)); \
- smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
__u.__val; \
})
#define READ_ONCE(x) __READ_ONCE(x, 1)
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 07/13] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb()
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (5 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 06/13] READ_ONCE: Remove smp_read_barrier_depends() invocation Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 08/13] locking/barriers: Remove definitions for [smp_]read_barrier_depends() Will Deacon
` (6 subsequent siblings)
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
In preparation for removing 'smp_read_barrier_depends()' altogether,
move the Alpha code over to using 'smp_rmb()' and 'smp_mb()' directly.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/alpha/include/asm/atomic.h | 16 ++++++++--------
arch/alpha/include/asm/pgtable.h | 10 +++++-----
mm/memory.c | 2 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index 2144530d1428..2f8f7e54792f 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -16,10 +16,10 @@
/*
* To ensure dependency ordering is preserved for the _relaxed and
- * _release atomics, an smp_read_barrier_depends() is unconditionally
- * inserted into the _relaxed variants, which are used to build the
- * barriered versions. Avoid redundant back-to-back fences in the
- * _acquire and _fence versions.
+ * _release atomics, an smp_mb() is unconditionally inserted into the
+ * _relaxed variants, which are used to build the barriered versions.
+ * Avoid redundant back-to-back fences in the _acquire and _fence
+ * versions.
*/
#define __atomic_acquire_fence()
#define __atomic_post_full_fence()
@@ -70,7 +70,7 @@ static inline int atomic_##op##_return_relaxed(int i, atomic_t *v) \
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result) \
:"Ir" (i), "m" (v->counter) : "memory"); \
- smp_read_barrier_depends(); \
+ smp_mb(); \
return result; \
}
@@ -88,7 +88,7 @@ static inline int atomic_fetch_##op##_relaxed(int i, atomic_t *v) \
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result) \
:"Ir" (i), "m" (v->counter) : "memory"); \
- smp_read_barrier_depends(); \
+ smp_mb(); \
return result; \
}
@@ -123,7 +123,7 @@ static __inline__ s64 atomic64_##op##_return_relaxed(s64 i, atomic64_t * v) \
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result) \
:"Ir" (i), "m" (v->counter) : "memory"); \
- smp_read_barrier_depends(); \
+ smp_mb(); \
return result; \
}
@@ -141,7 +141,7 @@ static __inline__ s64 atomic64_fetch_##op##_relaxed(s64 i, atomic64_t * v) \
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result) \
:"Ir" (i), "m" (v->counter) : "memory"); \
- smp_read_barrier_depends(); \
+ smp_mb(); \
return result; \
}
diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 065b57f408c3..b807793646c7 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -288,9 +288,9 @@ extern inline pte_t pte_mkspecial(pte_t pte) { return pte; }
#define pgd_offset(mm, address) ((mm)->pgd+pgd_index(address))
/*
- * The smp_read_barrier_depends() in the following functions are required to
- * order the load of *dir (the pointer in the top level page table) with any
- * subsequent load of the returned pmd_t *ret (ret is data dependent on *dir).
+ * The smp_rmb() in the following functions are required to order the load of
+ * *dir (the pointer in the top level page table) with any subsequent load of
+ * the returned pmd_t *ret (ret is data dependent on *dir).
*
* If this ordering is not enforced, the CPU might load an older value of
* *ret, which may be uninitialized data. See mm/memory.c:__pte_alloc for
@@ -304,7 +304,7 @@ extern inline pte_t pte_mkspecial(pte_t pte) { return pte; }
extern inline pmd_t * pmd_offset(pgd_t * dir, unsigned long address)
{
pmd_t *ret = (pmd_t *) pgd_page_vaddr(*dir) + ((address >> PMD_SHIFT) & (PTRS_PER_PAGE - 1));
- smp_read_barrier_depends(); /* see above */
+ smp_rmb(); /* see above */
return ret;
}
@@ -313,7 +313,7 @@ extern inline pte_t * pte_offset_kernel(pmd_t * dir, unsigned long address)
{
pte_t *ret = (pte_t *) pmd_page_vaddr(*dir)
+ ((address >> PAGE_SHIFT) & (PTRS_PER_PAGE - 1));
- smp_read_barrier_depends(); /* see above */
+ smp_rmb(); /* see above */
return ret;
}
diff --git a/mm/memory.c b/mm/memory.c
index b1ca51a079f2..c4a74e6d2c5c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -420,7 +420,7 @@ int __pte_alloc(struct mm_struct *mm, pmd_t *pmd)
* of a chain of data-dependent loads, meaning most CPUs (alpha
* being the notable exception) will already guarantee loads are
* seen in-order. See the alpha page table accessors for the
- * smp_read_barrier_depends() barriers in page table walking code.
+ * smp_rmb() barriers in page table walking code.
*/
smp_wmb(); /* Could be smp_wmb__xxx(before|after)_spin_lock */
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 08/13] locking/barriers: Remove definitions for [smp_]read_barrier_depends()
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (6 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 07/13] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb() Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 09/13] Documentation/barriers: Remove references to [smp_]read_barrier_depends() Will Deacon
` (5 subsequent siblings)
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
There are no remaining users of '[smp_]read_barrier_depends()', so
remove it from the generic implementation of 'barrier.h'.
Signed-off-by: Will Deacon <will@kernel.org>
---
include/asm-generic/barrier.h | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 85b28eb80b11..4b2a60f738b2 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -46,10 +46,6 @@
#define dma_wmb() wmb()
#endif
-#ifndef read_barrier_depends
-#define read_barrier_depends() do { } while (0)
-#endif
-
#ifndef __smp_mb
#define __smp_mb() mb()
#endif
@@ -62,10 +58,6 @@
#define __smp_wmb() wmb()
#endif
-#ifndef __smp_read_barrier_depends
-#define __smp_read_barrier_depends() read_barrier_depends()
-#endif
-
#ifdef CONFIG_SMP
#ifndef smp_mb
@@ -80,10 +72,6 @@
#define smp_wmb() __smp_wmb()
#endif
-#ifndef smp_read_barrier_depends
-#define smp_read_barrier_depends() __smp_read_barrier_depends()
-#endif
-
#else /* !CONFIG_SMP */
#ifndef smp_mb
@@ -98,10 +86,6 @@
#define smp_wmb() barrier()
#endif
-#ifndef smp_read_barrier_depends
-#define smp_read_barrier_depends() do { } while (0)
-#endif
-
#endif /* CONFIG_SMP */
#ifndef __smp_store_mb
@@ -196,7 +180,6 @@ do { \
#define virt_mb() __smp_mb()
#define virt_rmb() __smp_rmb()
#define virt_wmb() __smp_wmb()
-#define virt_read_barrier_depends() __smp_read_barrier_depends()
#define virt_store_mb(var, value) __smp_store_mb(var, value)
#define virt_mb__before_atomic() __smp_mb__before_atomic()
#define virt_mb__after_atomic() __smp_mb__after_atomic()
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 09/13] Documentation/barriers: Remove references to [smp_]read_barrier_depends()
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (7 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 08/13] locking/barriers: Remove definitions for [smp_]read_barrier_depends() Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-21 19:32 ` [PATCH] Documentation/barriers/kokr: " SeongJae Park
2019-11-08 17:01 ` [PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends() from informal doc Will Deacon
` (4 subsequent siblings)
13 siblings, 1 reply; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
The '[smp_]read_barrier_depends()' barrier macros no longer exist as
part of the Linux memory model, so remove all references to them from
the Documentation/ directory.
Although this is fairly mechanical on the whole, we drop the "CACHE
COHERENCY" section entirely from 'memory-barriers.txt' as it doesn't
make any sense now that the dependency barriers have been removed.
Signed-off-by: Will Deacon <will@kernel.org>
---
.../RCU/Design/Requirements/Requirements.html | 11 +-
Documentation/memory-barriers.txt | 156 +-----------------
2 files changed, 13 insertions(+), 154 deletions(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
index 467251f7fef6..4b8357def8ff 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -577,12 +577,11 @@ guarantee to also allow data elements to be removed from RCU-protected
linked data structures, again without disrupting RCU readers.
<p>
-This guarantee was only partially premeditated.
-DYNIX/ptx used an explicit memory barrier for publication, but had nothing
-resembling <tt>rcu_dereference()</tt> for subscription, nor did it
-have anything resembling the <tt>smp_read_barrier_depends()</tt>
-that was later subsumed into <tt>rcu_dereference()</tt> and later
-still into <tt>READ_ONCE()</tt>.
+This guarantee was only partially premeditated. DYNIX/ptx used an explicit
+memory barrier for publication, but had nothing resembling
+<tt>rcu_dereference()</tt> for subscription, nor did it have anything
+resembling the dependency-ordering barrier that was later subsumed into
+<tt>rcu_dereference()</tt> and later still into <tt>READ_ONCE()</tt>.
The need for these operations made itself known quite suddenly at a
late-1990s meeting with the DEC Alpha architects, back in the days when
DEC was still a free-standing company.
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 1adbb8a371c7..16b6aa7c5fe4 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -556,12 +556,12 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
DATA DEPENDENCY BARRIERS (HISTORICAL)
-------------------------------------
-As of v4.15 of the Linux kernel, an smp_read_barrier_depends() was
-added to READ_ONCE(), which means that about the only people who
-need to pay attention to this section are those working on DEC Alpha
-architecture-specific code and those working on READ_ONCE() itself.
-For those who need it, and for those who are interested in the history,
-here is the story of data-dependency barriers.
+As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for
+DEC Alpha, which means that about the only people who need to pay attention
+to this section are those working on DEC Alpha architecture-specific code
+and those working on READ_ONCE() itself. For those who need it, and for
+those who are interested in the history, here is the story of
+data-dependency barriers.
The usage requirements of data dependency barriers are a little subtle, and
it's not always obvious that they're needed. To illustrate, consider the
@@ -2709,144 +2709,6 @@ the properties of the memory window through which devices are accessed and/or
the use of any special device communication instructions the CPU may have.
-CACHE COHERENCY
----------------
-
-Life isn't quite as simple as it may appear above, however: for while the
-caches are expected to be coherent, there's no guarantee that that coherency
-will be ordered. This means that while changes made on one CPU will
-eventually become visible on all CPUs, there's no guarantee that they will
-become apparent in the same order on those other CPUs.
-
-
-Consider dealing with a system that has a pair of CPUs (1 & 2), each of which
-has a pair of parallel data caches (CPU 1 has A/B, and CPU 2 has C/D):
-
- :
- : +--------+
- : +---------+ | |
- +--------+ : +--->| Cache A |<------->| |
- | | : | +---------+ | |
- | CPU 1 |<---+ | |
- | | : | +---------+ | |
- +--------+ : +--->| Cache B |<------->| |
- : +---------+ | |
- : | Memory |
- : +---------+ | System |
- +--------+ : +--->| Cache C |<------->| |
- | | : | +---------+ | |
- | CPU 2 |<---+ | |
- | | : | +---------+ | |
- +--------+ : +--->| Cache D |<------->| |
- : +---------+ | |
- : +--------+
- :
-
-Imagine the system has the following properties:
-
- (*) an odd-numbered cache line may be in cache A, cache C or it may still be
- resident in memory;
-
- (*) an even-numbered cache line may be in cache B, cache D or it may still be
- resident in memory;
-
- (*) while the CPU core is interrogating one cache, the other cache may be
- making use of the bus to access the rest of the system - perhaps to
- displace a dirty cacheline or to do a speculative load;
-
- (*) each cache has a queue of operations that need to be applied to that cache
- to maintain coherency with the rest of the system;
-
- (*) the coherency queue is not flushed by normal loads to lines already
- present in the cache, even though the contents of the queue may
- potentially affect those loads.
-
-Imagine, then, that two writes are made on the first CPU, with a write barrier
-between them to guarantee that they will appear to reach that CPU's caches in
-the requisite order:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb(); Make sure change to v is visible before
- change to p
- <A:modify v=2> v is now in cache A exclusively
- p = &v;
- <B:modify p=&v> p is now in cache B exclusively
-
-The write memory barrier forces the other CPUs in the system to perceive that
-the local CPU's caches have apparently been updated in the correct order. But
-now imagine that the second CPU wants to read those values:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- ...
- q = p;
- x = *q;
-
-The above pair of reads may then fail to happen in the expected order, as the
-cacheline holding p may get updated in one of the second CPU's caches while
-the update to the cacheline holding v is delayed in the other of the second
-CPU's caches by some other cache event:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb();
- <A:modify v=2> <C:busy>
- <C:queue v=2>
- p = &v; q = p;
- <D:request p>
- <B:modify p=&v> <D:commit p=&v>
- <D:read p>
- x = *q;
- <C:read *q> Reads from v before v updated in cache
- <C:unbusy>
- <C:commit v=2>
-
-Basically, while both cachelines will be updated on CPU 2 eventually, there's
-no guarantee that, without intervention, the order of update will be the same
-as that committed on CPU 1.
-
-
-To intervene, we need to interpolate a data dependency barrier or a read
-barrier between the loads (which as of v4.15 is supplied unconditionally
-by the READ_ONCE() macro). This will force the cache to commit its
-coherency queue before processing any further requests:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb();
- <A:modify v=2> <C:busy>
- <C:queue v=2>
- p = &v; q = p;
- <D:request p>
- <B:modify p=&v> <D:commit p=&v>
- <D:read p>
- smp_read_barrier_depends()
- <C:unbusy>
- <C:commit v=2>
- x = *q;
- <C:read *q> Reads from v after v updated in cache
-
-
-This sort of problem can be encountered on DEC Alpha processors as they have a
-split cache that improves performance by making better use of the data bus.
-While most CPUs do imply a data dependency barrier on the read when a memory
-access depends on a read, not all do, so it may not be relied on.
-
-Other CPUs may also have split caches, but must coordinate between the various
-cachelets for normal memory accesses. The semantics of the Alpha removes the
-need for hardware coordination in the absence of memory barriers, which
-permitted Alpha to sport higher CPU clock rates back in the day. However,
-please note that (again, as of v4.15) smp_read_barrier_depends() should not
-be used except in Alpha arch-specific code and within the READ_ONCE() macro.
-
-
CACHE COHERENCY VS DMA
----------------------
@@ -3010,10 +2872,8 @@ caches with the memory coherence system, thus making it seem like pointer
changes vs new data occur in the right order.
The Alpha defines the Linux kernel's memory model, although as of v4.15
-the Linux kernel's addition of smp_read_barrier_depends() to READ_ONCE()
-greatly reduced Alpha's impact on the memory model.
-
-See the subsection on "Cache Coherency" above.
+the Linux kernel's addition of smp_mb() to READ_ONCE() on Alpha greatly
+reduced its impact on the memory model.
VIRTUAL MACHINE GUESTS
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-11-08 17:01 ` [PATCH 09/13] Documentation/barriers: Remove references to [smp_]read_barrier_depends() Will Deacon
@ 2019-11-21 19:32 ` SeongJae Park
2019-11-26 22:20 ` Paul E. McKenney
2019-11-29 18:08 ` [PATCH v2] " SeongJae Park
0 siblings, 2 replies; 35+ messages in thread
From: SeongJae Park @ 2019-11-21 19:32 UTC (permalink / raw)
To: will; +Cc: paulmck, linux-kernel, SeongJae Park
This commit translates commit 8088616d4ca6 ("Documentation/barriers:
Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
into Korean.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
.../translations/ko_KR/memory-barriers.txt | 146 +-----------------
1 file changed, 3 insertions(+), 143 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 2774624ee843..42509b86542f 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
데이터 의존성 배리어 (역사적)
-----------------------------
-리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
+리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
@@ -2714,144 +2714,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
수도 있습니다.
-캐시 일관성
------------
-
-하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
-기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
-만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
-CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
-
-
-두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
-CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
-봅시다:
-
- :
- : +--------+
- : +---------+ | |
- +--------+ : +--->| Cache A |<------->| |
- | | : | +---------+ | |
- | CPU 1 |<---+ | |
- | | : | +---------+ | |
- +--------+ : +--->| Cache B |<------->| |
- : +---------+ | |
- : | Memory |
- : +---------+ | System |
- +--------+ : +--->| Cache C |<------->| |
- | | : | +---------+ | |
- | CPU 2 |<---+ | |
- | | : | +---------+ | |
- +--------+ : +--->| Cache D |<------->| |
- : +---------+ | |
- : +--------+
- :
-
-이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
-
- (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
-
- (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
-
- (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
- 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
- 액세스 하기 위해 버스를 사용할 수 있음;
-
- (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
- 적용되어야 할 오퍼레이션들의 큐를 가짐;
-
- (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
- 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
- 할지라도 그러함.
-
-이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
-요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
-배리어를 사용하는 상황을 상상해 봅시다:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
- 분명히 함
- <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
- p = &v;
- <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
-
-여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
-시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
-읽으려 하는 상황을 생각해 봅시다:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- ...
- q = p;
- x = *q;
-
-위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
-의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
-업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
-업데이트 되어버렸을 수 있기 때문입니다.
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb();
- <A:modify v=2> <C:busy>
- <C:queue v=2>
- p = &v; q = p;
- <D:request p>
- <B:modify p=&v> <D:commit p=&v>
- <D:read p>
- x = *q;
- <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
- <C:unbusy>
- <C:commit v=2>
-
-기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
-별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
-것이라는 보장이 없습니다.
-
-
-여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
-사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
-그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
-처리하도록 강제하게 됩니다.
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb();
- <A:modify v=2> <C:busy>
- <C:queue v=2>
- p = &v; q = p;
- <D:request p>
- <B:modify p=&v> <D:commit p=&v>
- <D:read p>
- smp_read_barrier_depends()
- <C:unbusy>
- <C:commit v=2>
- x = *q;
- <C:read *q> 캐시에 업데이트 된 v 를 읽음
-
-
-이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
-데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
-때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
-오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
-아니기 때문에 이점에 의존해선 안됩니다.
-
-다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
-액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
-약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
-사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
-더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
-이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
-smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
-
-
캐시 일관성 VS DMA
------------------
@@ -3012,10 +2874,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
-부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
-Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
-
-위의 "캐시 일관성" 서브섹션을 참고하세요.
+부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
+Alpha 의 영향력이 크게 줄어들었습니다.
가상 머신 게스트
--
2.17.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* Re: [PATCH] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-11-21 19:32 ` [PATCH] Documentation/barriers/kokr: " SeongJae Park
@ 2019-11-26 22:20 ` Paul E. McKenney
2019-11-29 18:08 ` [PATCH v2] " SeongJae Park
1 sibling, 0 replies; 35+ messages in thread
From: Paul E. McKenney @ 2019-11-26 22:20 UTC (permalink / raw)
To: SeongJae Park; +Cc: will, linux-kernel
On Thu, Nov 21, 2019 at 08:32:09PM +0100, SeongJae Park wrote:
> This commit translates commit 8088616d4ca6 ("Documentation/barriers:
> Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
> into Korean.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
>
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
Queued, thank you, SeongJae!
Thanx, Paul
> ---
> .../translations/ko_KR/memory-barriers.txt | 146 +-----------------
> 1 file changed, 3 insertions(+), 143 deletions(-)
>
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> index 2774624ee843..42509b86542f 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
> 데이터 의존성 배리어 (역사적)
> -----------------------------
>
> -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
> +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
> 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
> 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
> 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
> @@ -2714,144 +2714,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
> 수도 있습니다.
>
>
> -캐시 일관성
> ------------
> -
> -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
> -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
> -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
> -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
> -
> -
> -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
> -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
> -봅시다:
> -
> - :
> - : +--------+
> - : +---------+ | |
> - +--------+ : +--->| Cache A |<------->| |
> - | | : | +---------+ | |
> - | CPU 1 |<---+ | |
> - | | : | +---------+ | |
> - +--------+ : +--->| Cache B |<------->| |
> - : +---------+ | |
> - : | Memory |
> - : +---------+ | System |
> - +--------+ : +--->| Cache C |<------->| |
> - | | : | +---------+ | |
> - | CPU 2 |<---+ | |
> - | | : | +---------+ | |
> - +--------+ : +--->| Cache D |<------->| |
> - : +---------+ | |
> - : +--------+
> - :
> -
> -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
> -
> - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
> -
> - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
> -
> - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
> - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
> - 액세스 하기 위해 버스를 사용할 수 있음;
> -
> - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
> - 적용되어야 할 오퍼레이션들의 큐를 가짐;
> -
> - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
> - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
> - 할지라도 그러함.
> -
> -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
> -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
> -배리어를 사용하는 상황을 상상해 봅시다:
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - u == 0, v == 1 and p == &u, q == &u
> - v = 2;
> - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
> - 분명히 함
> - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
> - p = &v;
> - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
> -
> -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
> -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
> -읽으려 하는 상황을 생각해 봅시다:
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - ...
> - q = p;
> - x = *q;
> -
> -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
> -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
> -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
> -업데이트 되어버렸을 수 있기 때문입니다.
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - u == 0, v == 1 and p == &u, q == &u
> - v = 2;
> - smp_wmb();
> - <A:modify v=2> <C:busy>
> - <C:queue v=2>
> - p = &v; q = p;
> - <D:request p>
> - <B:modify p=&v> <D:commit p=&v>
> - <D:read p>
> - x = *q;
> - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
> - <C:unbusy>
> - <C:commit v=2>
> -
> -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
> -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
> -것이라는 보장이 없습니다.
> -
> -
> -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
> -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
> -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
> -처리하도록 강제하게 됩니다.
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - u == 0, v == 1 and p == &u, q == &u
> - v = 2;
> - smp_wmb();
> - <A:modify v=2> <C:busy>
> - <C:queue v=2>
> - p = &v; q = p;
> - <D:request p>
> - <B:modify p=&v> <D:commit p=&v>
> - <D:read p>
> - smp_read_barrier_depends()
> - <C:unbusy>
> - <C:commit v=2>
> - x = *q;
> - <C:read *q> 캐시에 업데이트 된 v 를 읽음
> -
> -
> -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
> -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
> -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
> -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
> -아니기 때문에 이점에 의존해선 안됩니다.
> -
> -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
> -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
> -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
> -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
> -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
> -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
> -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
> -
> -
> 캐시 일관성 VS DMA
> ------------------
>
> @@ -3012,10 +2874,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
> 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
>
> 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
> -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
> -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
> -
> -위의 "캐시 일관성" 서브섹션을 참고하세요.
> +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
> +Alpha 의 영향력이 크게 줄어들었습니다.
>
>
> 가상 머신 게스트
> --
> 2.17.2
>
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-11-21 19:32 ` [PATCH] Documentation/barriers/kokr: " SeongJae Park
2019-11-26 22:20 ` Paul E. McKenney
@ 2019-11-29 18:08 ` SeongJae Park
2019-12-06 17:20 ` SeongJae Park
1 sibling, 1 reply; 35+ messages in thread
From: SeongJae Park @ 2019-11-29 18:08 UTC (permalink / raw)
To: paulmck, will; +Cc: linux-kernel, linux-doc, notify, SeongJae Park
Paul, thank you for waiting long. I got reviewed by another Korean
hacker, Yunjae.
Changes from v1 (https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/)
- Get a review from Yunjae
- Minor wordsmith based on the review comment
- Rebased on git://git.lwn.net/linux.git tags/docs-5.5
- Update author's email address
--------------------------------- >8 -----------------------------------------
This commit translates commit 8088616d4ca6 ("Documentation/barriers:
Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
into Korean.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
---
.../translations/ko_KR/memory-barriers.txt | 146 +-----------------
1 file changed, 3 insertions(+), 143 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index f07c40a068b5..a8d26df9360b 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
데이터 의존성 배리어 (역사적)
-----------------------------
-리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
+리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
@@ -2661,144 +2661,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
수도 있습니다.
-캐시 일관성
------------
-
-하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
-기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
-만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
-CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
-
-
-두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
-CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
-봅시다:
-
- :
- : +--------+
- : +---------+ | |
- +--------+ : +--->| Cache A |<------->| |
- | | : | +---------+ | |
- | CPU 1 |<---+ | |
- | | : | +---------+ | |
- +--------+ : +--->| Cache B |<------->| |
- : +---------+ | |
- : | Memory |
- : +---------+ | System |
- +--------+ : +--->| Cache C |<------->| |
- | | : | +---------+ | |
- | CPU 2 |<---+ | |
- | | : | +---------+ | |
- +--------+ : +--->| Cache D |<------->| |
- : +---------+ | |
- : +--------+
- :
-
-이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
-
- (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
-
- (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
-
- (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
- 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
- 액세스 하기 위해 버스를 사용할 수 있음;
-
- (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
- 적용되어야 할 오퍼레이션들의 큐를 가짐;
-
- (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
- 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
- 할지라도 그러함.
-
-이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
-요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
-배리어를 사용하는 상황을 상상해 봅시다:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
- 분명히 함
- <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
- p = &v;
- <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
-
-여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
-시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
-읽으려 하는 상황을 생각해 봅시다:
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- ...
- q = p;
- x = *q;
-
-위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
-의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
-업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
-업데이트 되어버렸을 수 있기 때문입니다.
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb();
- <A:modify v=2> <C:busy>
- <C:queue v=2>
- p = &v; q = p;
- <D:request p>
- <B:modify p=&v> <D:commit p=&v>
- <D:read p>
- x = *q;
- <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
- <C:unbusy>
- <C:commit v=2>
-
-기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
-별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
-것이라는 보장이 없습니다.
-
-
-여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
-사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
-그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
-처리하도록 강제하게 됩니다.
-
- CPU 1 CPU 2 COMMENT
- =============== =============== =======================================
- u == 0, v == 1 and p == &u, q == &u
- v = 2;
- smp_wmb();
- <A:modify v=2> <C:busy>
- <C:queue v=2>
- p = &v; q = p;
- <D:request p>
- <B:modify p=&v> <D:commit p=&v>
- <D:read p>
- smp_read_barrier_depends()
- <C:unbusy>
- <C:commit v=2>
- x = *q;
- <C:read *q> 캐시에 업데이트 된 v 를 읽음
-
-
-이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
-데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
-때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
-오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
-아니기 때문에 이점에 의존해선 안됩니다.
-
-다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
-액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
-약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
-사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
-더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
-이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
-smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
-
-
캐시 일관성 VS DMA
------------------
@@ -2959,10 +2821,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
-부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
-Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
-
-위의 "캐시 일관성" 서브섹션을 참고하세요.
+부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
+Alpha 의 영향력이 크게 줄어들었습니다.
가상 머신 게스트
--
2.17.2
^ permalink raw reply related [flat|nested] 35+ messages in thread* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-11-29 18:08 ` [PATCH v2] " SeongJae Park
@ 2019-12-06 17:20 ` SeongJae Park
2019-12-06 20:44 ` Paul E. McKenney
0 siblings, 1 reply; 35+ messages in thread
From: SeongJae Park @ 2019-12-06 17:20 UTC (permalink / raw)
To: Paul E. McKenney, Will Deacon; +Cc: LKML, linux-doc, notify, SeongJae Park
Hello Paul and Will,
On Fri, Nov 29, 2019 at 7:09 PM SeongJae Park <sj38.park@gmail.com> wrote:
>
> Paul, thank you for waiting long. I got reviewed by another Korean
> hacker, Yunjae.
>
> Changes from v1 (https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/)
> - Get a review from Yunjae
> - Minor wordsmith based on the review comment
> - Rebased on git://git.lwn.net/linux.git tags/docs-5.5
> - Update author's email address
May I ask your comments?
Thanks,
SeongJae Park
>
> --------------------------------- >8 -----------------------------------------
>
> This commit translates commit 8088616d4ca6 ("Documentation/barriers:
> Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
> into Korean.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
>
> Signed-off-by: SeongJae Park <sjpark@amazon.de>
> Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
>
> ---
> .../translations/ko_KR/memory-barriers.txt | 146 +-----------------
> 1 file changed, 3 insertions(+), 143 deletions(-)
>
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> index f07c40a068b5..a8d26df9360b 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
> 데이터 의존성 배리어 (역사적)
> -----------------------------
>
> -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
> +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
> 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
> 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
> 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
> @@ -2661,144 +2661,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
> 수도 있습니다.
>
>
> -캐시 일관성
> ------------
> -
> -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
> -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
> -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
> -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
> -
> -
> -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
> -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
> -봅시다:
> -
> - :
> - : +--------+
> - : +---------+ | |
> - +--------+ : +--->| Cache A |<------->| |
> - | | : | +---------+ | |
> - | CPU 1 |<---+ | |
> - | | : | +---------+ | |
> - +--------+ : +--->| Cache B |<------->| |
> - : +---------+ | |
> - : | Memory |
> - : +---------+ | System |
> - +--------+ : +--->| Cache C |<------->| |
> - | | : | +---------+ | |
> - | CPU 2 |<---+ | |
> - | | : | +---------+ | |
> - +--------+ : +--->| Cache D |<------->| |
> - : +---------+ | |
> - : +--------+
> - :
> -
> -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
> -
> - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
> -
> - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
> -
> - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
> - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
> - 액세스 하기 위해 버스를 사용할 수 있음;
> -
> - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
> - 적용되어야 할 오퍼레이션들의 큐를 가짐;
> -
> - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
> - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
> - 할지라도 그러함.
> -
> -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
> -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
> -배리어를 사용하는 상황을 상상해 봅시다:
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - u == 0, v == 1 and p == &u, q == &u
> - v = 2;
> - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
> - 분명히 함
> - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
> - p = &v;
> - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
> -
> -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
> -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
> -읽으려 하는 상황을 생각해 봅시다:
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - ...
> - q = p;
> - x = *q;
> -
> -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
> -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
> -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
> -업데이트 되어버렸을 수 있기 때문입니다.
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - u == 0, v == 1 and p == &u, q == &u
> - v = 2;
> - smp_wmb();
> - <A:modify v=2> <C:busy>
> - <C:queue v=2>
> - p = &v; q = p;
> - <D:request p>
> - <B:modify p=&v> <D:commit p=&v>
> - <D:read p>
> - x = *q;
> - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
> - <C:unbusy>
> - <C:commit v=2>
> -
> -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
> -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
> -것이라는 보장이 없습니다.
> -
> -
> -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
> -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
> -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
> -처리하도록 강제하게 됩니다.
> -
> - CPU 1 CPU 2 COMMENT
> - =============== =============== =======================================
> - u == 0, v == 1 and p == &u, q == &u
> - v = 2;
> - smp_wmb();
> - <A:modify v=2> <C:busy>
> - <C:queue v=2>
> - p = &v; q = p;
> - <D:request p>
> - <B:modify p=&v> <D:commit p=&v>
> - <D:read p>
> - smp_read_barrier_depends()
> - <C:unbusy>
> - <C:commit v=2>
> - x = *q;
> - <C:read *q> 캐시에 업데이트 된 v 를 읽음
> -
> -
> -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
> -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
> -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
> -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
> -아니기 때문에 이점에 의존해선 안됩니다.
> -
> -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
> -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
> -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
> -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
> -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
> -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
> -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
> -
> -
> 캐시 일관성 VS DMA
> ------------------
>
> @@ -2959,10 +2821,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
> 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
>
> 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
> -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
> -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
> -
> -위의 "캐시 일관성" 서브섹션을 참고하세요.
> +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
> +Alpha 의 영향력이 크게 줄어들었습니다.
>
>
> 가상 머신 게스트
> --
> 2.17.2
>
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-06 17:20 ` SeongJae Park
@ 2019-12-06 20:44 ` Paul E. McKenney
2019-12-06 21:29 ` SeongJae Park
0 siblings, 1 reply; 35+ messages in thread
From: Paul E. McKenney @ 2019-12-06 20:44 UTC (permalink / raw)
To: SeongJae Park; +Cc: Will Deacon, LKML, linux-doc, notify, SeongJae Park
On Fri, Dec 06, 2019 at 06:20:51PM +0100, SeongJae Park wrote:
> Hello Paul and Will,
>
> On Fri, Nov 29, 2019 at 7:09 PM SeongJae Park <sj38.park@gmail.com> wrote:
> >
> > Paul, thank you for waiting long. I got reviewed by another Korean
> > hacker, Yunjae.
> >
> > Changes from v1 (https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/)
> > - Get a review from Yunjae
> > - Minor wordsmith based on the review comment
> > - Rebased on git://git.lwn.net/linux.git tags/docs-5.5
> > - Update author's email address
>
> May I ask your comments?
I thought that Jon Corbet had already queued these. Did I miss some?
Thanx, Paul
> Thanks,
> SeongJae Park
>
> >
> > --------------------------------- >8 -----------------------------------------
> >
> > This commit translates commit 8088616d4ca6 ("Documentation/barriers:
> > Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
> > into Korean.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
> >
> > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> >
> > ---
> > .../translations/ko_KR/memory-barriers.txt | 146 +-----------------
> > 1 file changed, 3 insertions(+), 143 deletions(-)
> >
> > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> > index f07c40a068b5..a8d26df9360b 100644
> > --- a/Documentation/translations/ko_KR/memory-barriers.txt
> > +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> > @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
> > 데이터 의존성 배리어 (역사적)
> > -----------------------------
> >
> > -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
> > +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
> > 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
> > 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
> > 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
> > @@ -2661,144 +2661,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
> > 수도 있습니다.
> >
> >
> > -캐시 일관성
> > ------------
> > -
> > -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
> > -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
> > -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
> > -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
> > -
> > -
> > -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
> > -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
> > -봅시다:
> > -
> > - :
> > - : +--------+
> > - : +---------+ | |
> > - +--------+ : +--->| Cache A |<------->| |
> > - | | : | +---------+ | |
> > - | CPU 1 |<---+ | |
> > - | | : | +---------+ | |
> > - +--------+ : +--->| Cache B |<------->| |
> > - : +---------+ | |
> > - : | Memory |
> > - : +---------+ | System |
> > - +--------+ : +--->| Cache C |<------->| |
> > - | | : | +---------+ | |
> > - | CPU 2 |<---+ | |
> > - | | : | +---------+ | |
> > - +--------+ : +--->| Cache D |<------->| |
> > - : +---------+ | |
> > - : +--------+
> > - :
> > -
> > -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
> > -
> > - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
> > -
> > - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
> > -
> > - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
> > - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
> > - 액세스 하기 위해 버스를 사용할 수 있음;
> > -
> > - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
> > - 적용되어야 할 오퍼레이션들의 큐를 가짐;
> > -
> > - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
> > - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
> > - 할지라도 그러함.
> > -
> > -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
> > -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
> > -배리어를 사용하는 상황을 상상해 봅시다:
> > -
> > - CPU 1 CPU 2 COMMENT
> > - =============== =============== =======================================
> > - u == 0, v == 1 and p == &u, q == &u
> > - v = 2;
> > - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
> > - 분명히 함
> > - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
> > - p = &v;
> > - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
> > -
> > -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
> > -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
> > -읽으려 하는 상황을 생각해 봅시다:
> > -
> > - CPU 1 CPU 2 COMMENT
> > - =============== =============== =======================================
> > - ...
> > - q = p;
> > - x = *q;
> > -
> > -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
> > -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
> > -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
> > -업데이트 되어버렸을 수 있기 때문입니다.
> > -
> > - CPU 1 CPU 2 COMMENT
> > - =============== =============== =======================================
> > - u == 0, v == 1 and p == &u, q == &u
> > - v = 2;
> > - smp_wmb();
> > - <A:modify v=2> <C:busy>
> > - <C:queue v=2>
> > - p = &v; q = p;
> > - <D:request p>
> > - <B:modify p=&v> <D:commit p=&v>
> > - <D:read p>
> > - x = *q;
> > - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
> > - <C:unbusy>
> > - <C:commit v=2>
> > -
> > -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
> > -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
> > -것이라는 보장이 없습니다.
> > -
> > -
> > -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
> > -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
> > -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
> > -처리하도록 강제하게 됩니다.
> > -
> > - CPU 1 CPU 2 COMMENT
> > - =============== =============== =======================================
> > - u == 0, v == 1 and p == &u, q == &u
> > - v = 2;
> > - smp_wmb();
> > - <A:modify v=2> <C:busy>
> > - <C:queue v=2>
> > - p = &v; q = p;
> > - <D:request p>
> > - <B:modify p=&v> <D:commit p=&v>
> > - <D:read p>
> > - smp_read_barrier_depends()
> > - <C:unbusy>
> > - <C:commit v=2>
> > - x = *q;
> > - <C:read *q> 캐시에 업데이트 된 v 를 읽음
> > -
> > -
> > -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
> > -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
> > -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
> > -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
> > -아니기 때문에 이점에 의존해선 안됩니다.
> > -
> > -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
> > -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
> > -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
> > -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
> > -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
> > -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
> > -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
> > -
> > -
> > 캐시 일관성 VS DMA
> > ------------------
> >
> > @@ -2959,10 +2821,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
> > 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
> >
> > 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
> > -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
> > -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
> > -
> > -위의 "캐시 일관성" 서브섹션을 참고하세요.
> > +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
> > +Alpha 의 영향력이 크게 줄어들었습니다.
> >
> >
> > 가상 머신 게스트
> > --
> > 2.17.2
> >
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-06 20:44 ` Paul E. McKenney
@ 2019-12-06 21:29 ` SeongJae Park
2019-12-06 22:08 ` Paul E. McKenney
0 siblings, 1 reply; 35+ messages in thread
From: SeongJae Park @ 2019-12-06 21:29 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Will Deacon, LKML, linux-doc, notify, SeongJae Park
On Fri, Dec 6, 2019 at 9:44 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Fri, Dec 06, 2019 at 06:20:51PM +0100, SeongJae Park wrote:
> > Hello Paul and Will,
> >
> > On Fri, Nov 29, 2019 at 7:09 PM SeongJae Park <sj38.park@gmail.com> wrote:
> > >
> > > Paul, thank you for waiting long. I got reviewed by another Korean
> > > hacker, Yunjae.
> > >
> > > Changes from v1 (https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/)
> > > - Get a review from Yunjae
> > > - Minor wordsmith based on the review comment
> > > - Rebased on git://git.lwn.net/linux.git tags/docs-5.5
> > > - Update author's email address
> >
> > May I ask your comments?
>
> I thought that Jon Corbet had already queued these. Did I miss some?
This patch has not queued by Jon, indeed. I haven't CC-ed neither Jon, nor
linux-doc for the 1st version of this patch because this is a followup of
Will's patch[1] and the Will's patch also have not CC-ed them.
I sent another patchset[2] for documents simultaneously but CC-ed Jon and
linux-doc for the patch, because the patchset is a followup of the commits
which already merged in Torvalds's tree. The patchset has queued by both of
you and then you agreed to merge it by Jon's tree. I guess I made the
confusion in this way. Sorry for making such confusion. Anyway, this patch
is not queued in any tree, AFIK.
Thanks,
SeongJae Park
[1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
[2] https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@gmail.com/
>
> Thanx, Paul
>
> > Thanks,
> > SeongJae Park
> >
> > >
> > > --------------------------------- >8 -----------------------------------------
> > >
> > > This commit translates commit 8088616d4ca6 ("Documentation/barriers:
> > > Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
> > > into Korean.
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
> > >
> > > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > > Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> > >
> > > ---
> > > .../translations/ko_KR/memory-barriers.txt | 146 +-----------------
> > > 1 file changed, 3 insertions(+), 143 deletions(-)
> > >
> > > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> > > index f07c40a068b5..a8d26df9360b 100644
> > > --- a/Documentation/translations/ko_KR/memory-barriers.txt
> > > +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> > > @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
> > > 데이터 의존성 배리어 (역사적)
> > > -----------------------------
> > >
> > > -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
> > > +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
> > > 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
> > > 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
> > > 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
> > > @@ -2661,144 +2661,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
> > > 수도 있습니다.
> > >
> > >
> > > -캐시 일관성
> > > ------------
> > > -
> > > -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
> > > -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
> > > -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
> > > -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
> > > -
> > > -
> > > -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
> > > -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
> > > -봅시다:
> > > -
> > > - :
> > > - : +--------+
> > > - : +---------+ | |
> > > - +--------+ : +--->| Cache A |<------->| |
> > > - | | : | +---------+ | |
> > > - | CPU 1 |<---+ | |
> > > - | | : | +---------+ | |
> > > - +--------+ : +--->| Cache B |<------->| |
> > > - : +---------+ | |
> > > - : | Memory |
> > > - : +---------+ | System |
> > > - +--------+ : +--->| Cache C |<------->| |
> > > - | | : | +---------+ | |
> > > - | CPU 2 |<---+ | |
> > > - | | : | +---------+ | |
> > > - +--------+ : +--->| Cache D |<------->| |
> > > - : +---------+ | |
> > > - : +--------+
> > > - :
> > > -
> > > -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
> > > -
> > > - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
> > > -
> > > - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
> > > -
> > > - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
> > > - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
> > > - 액세스 하기 위해 버스를 사용할 수 있음;
> > > -
> > > - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
> > > - 적용되어야 할 오퍼레이션들의 큐를 가짐;
> > > -
> > > - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
> > > - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
> > > - 할지라도 그러함.
> > > -
> > > -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
> > > -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
> > > -배리어를 사용하는 상황을 상상해 봅시다:
> > > -
> > > - CPU 1 CPU 2 COMMENT
> > > - =============== =============== =======================================
> > > - u == 0, v == 1 and p == &u, q == &u
> > > - v = 2;
> > > - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
> > > - 분명히 함
> > > - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
> > > - p = &v;
> > > - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
> > > -
> > > -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
> > > -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
> > > -읽으려 하는 상황을 생각해 봅시다:
> > > -
> > > - CPU 1 CPU 2 COMMENT
> > > - =============== =============== =======================================
> > > - ...
> > > - q = p;
> > > - x = *q;
> > > -
> > > -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
> > > -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
> > > -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
> > > -업데이트 되어버렸을 수 있기 때문입니다.
> > > -
> > > - CPU 1 CPU 2 COMMENT
> > > - =============== =============== =======================================
> > > - u == 0, v == 1 and p == &u, q == &u
> > > - v = 2;
> > > - smp_wmb();
> > > - <A:modify v=2> <C:busy>
> > > - <C:queue v=2>
> > > - p = &v; q = p;
> > > - <D:request p>
> > > - <B:modify p=&v> <D:commit p=&v>
> > > - <D:read p>
> > > - x = *q;
> > > - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
> > > - <C:unbusy>
> > > - <C:commit v=2>
> > > -
> > > -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
> > > -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
> > > -것이라는 보장이 없습니다.
> > > -
> > > -
> > > -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
> > > -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
> > > -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
> > > -처리하도록 강제하게 됩니다.
> > > -
> > > - CPU 1 CPU 2 COMMENT
> > > - =============== =============== =======================================
> > > - u == 0, v == 1 and p == &u, q == &u
> > > - v = 2;
> > > - smp_wmb();
> > > - <A:modify v=2> <C:busy>
> > > - <C:queue v=2>
> > > - p = &v; q = p;
> > > - <D:request p>
> > > - <B:modify p=&v> <D:commit p=&v>
> > > - <D:read p>
> > > - smp_read_barrier_depends()
> > > - <C:unbusy>
> > > - <C:commit v=2>
> > > - x = *q;
> > > - <C:read *q> 캐시에 업데이트 된 v 를 읽음
> > > -
> > > -
> > > -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
> > > -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
> > > -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
> > > -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
> > > -아니기 때문에 이점에 의존해선 안됩니다.
> > > -
> > > -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
> > > -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
> > > -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
> > > -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
> > > -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
> > > -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
> > > -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
> > > -
> > > -
> > > 캐시 일관성 VS DMA
> > > ------------------
> > >
> > > @@ -2959,10 +2821,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
> > > 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
> > >
> > > 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
> > > -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
> > > -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
> > > -
> > > -위의 "캐시 일관성" 서브섹션을 참고하세요.
> > > +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
> > > +Alpha 의 영향력이 크게 줄어들었습니다.
> > >
> > >
> > > 가상 머신 게스트
> > > --
> > > 2.17.2
> > >
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-06 21:29 ` SeongJae Park
@ 2019-12-06 22:08 ` Paul E. McKenney
2019-12-06 22:38 ` SeongJae Park
0 siblings, 1 reply; 35+ messages in thread
From: Paul E. McKenney @ 2019-12-06 22:08 UTC (permalink / raw)
To: SeongJae Park; +Cc: Will Deacon, LKML, linux-doc, notify, SeongJae Park
On Fri, Dec 06, 2019 at 10:29:50PM +0100, SeongJae Park wrote:
> On Fri, Dec 6, 2019 at 9:44 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Fri, Dec 06, 2019 at 06:20:51PM +0100, SeongJae Park wrote:
> > > Hello Paul and Will,
> > >
> > > On Fri, Nov 29, 2019 at 7:09 PM SeongJae Park <sj38.park@gmail.com> wrote:
> > > >
> > > > Paul, thank you for waiting long. I got reviewed by another Korean
> > > > hacker, Yunjae.
> > > >
> > > > Changes from v1 (https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/)
> > > > - Get a review from Yunjae
> > > > - Minor wordsmith based on the review comment
> > > > - Rebased on git://git.lwn.net/linux.git tags/docs-5.5
> > > > - Update author's email address
> > >
> > > May I ask your comments?
> >
> > I thought that Jon Corbet had already queued these. Did I miss some?
>
> This patch has not queued by Jon, indeed. I haven't CC-ed neither Jon, nor
> linux-doc for the 1st version of this patch because this is a followup of
> Will's patch[1] and the Will's patch also have not CC-ed them.
>
> I sent another patchset[2] for documents simultaneously but CC-ed Jon and
> linux-doc for the patch, because the patchset is a followup of the commits
> which already merged in Torvalds's tree. The patchset has queued by both of
> you and then you agreed to merge it by Jon's tree. I guess I made the
> confusion in this way. Sorry for making such confusion. Anyway, this patch
> is not queued in any tree, AFIK.
Not a problem at all!
But since Jon seems to be taking these in his capacity and Documentation
maintainer, could you please resend CCing him? If we have these changes
scattered across too many trees, someone is going to get confused,
and it probably will be me. ;-)
Thanx, Paul
> Thanks,
> SeongJae Park
>
>
> [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
> [2] https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@gmail.com/
>
> >
> > Thanx, Paul
> >
> > > Thanks,
> > > SeongJae Park
> > >
> > > >
> > > > --------------------------------- >8 -----------------------------------------
> > > >
> > > > This commit translates commit 8088616d4ca6 ("Documentation/barriers:
> > > > Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
> > > > into Korean.
> > > >
> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
> > > >
> > > > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > > > Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> > > >
> > > > ---
> > > > .../translations/ko_KR/memory-barriers.txt | 146 +-----------------
> > > > 1 file changed, 3 insertions(+), 143 deletions(-)
> > > >
> > > > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> > > > index f07c40a068b5..a8d26df9360b 100644
> > > > --- a/Documentation/translations/ko_KR/memory-barriers.txt
> > > > +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> > > > @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
> > > > 데이터 의존성 배리어 (역사적)
> > > > -----------------------------
> > > >
> > > > -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
> > > > +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
> > > > 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
> > > > 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
> > > > 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
> > > > @@ -2661,144 +2661,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
> > > > 수도 있습니다.
> > > >
> > > >
> > > > -캐시 일관성
> > > > ------------
> > > > -
> > > > -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
> > > > -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
> > > > -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
> > > > -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
> > > > -
> > > > -
> > > > -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
> > > > -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
> > > > -봅시다:
> > > > -
> > > > - :
> > > > - : +--------+
> > > > - : +---------+ | |
> > > > - +--------+ : +--->| Cache A |<------->| |
> > > > - | | : | +---------+ | |
> > > > - | CPU 1 |<---+ | |
> > > > - | | : | +---------+ | |
> > > > - +--------+ : +--->| Cache B |<------->| |
> > > > - : +---------+ | |
> > > > - : | Memory |
> > > > - : +---------+ | System |
> > > > - +--------+ : +--->| Cache C |<------->| |
> > > > - | | : | +---------+ | |
> > > > - | CPU 2 |<---+ | |
> > > > - | | : | +---------+ | |
> > > > - +--------+ : +--->| Cache D |<------->| |
> > > > - : +---------+ | |
> > > > - : +--------+
> > > > - :
> > > > -
> > > > -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
> > > > -
> > > > - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
> > > > -
> > > > - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
> > > > -
> > > > - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
> > > > - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
> > > > - 액세스 하기 위해 버스를 사용할 수 있음;
> > > > -
> > > > - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
> > > > - 적용되어야 할 오퍼레이션들의 큐를 가짐;
> > > > -
> > > > - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
> > > > - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
> > > > - 할지라도 그러함.
> > > > -
> > > > -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
> > > > -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
> > > > -배리어를 사용하는 상황을 상상해 봅시다:
> > > > -
> > > > - CPU 1 CPU 2 COMMENT
> > > > - =============== =============== =======================================
> > > > - u == 0, v == 1 and p == &u, q == &u
> > > > - v = 2;
> > > > - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
> > > > - 분명히 함
> > > > - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
> > > > - p = &v;
> > > > - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
> > > > -
> > > > -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
> > > > -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
> > > > -읽으려 하는 상황을 생각해 봅시다:
> > > > -
> > > > - CPU 1 CPU 2 COMMENT
> > > > - =============== =============== =======================================
> > > > - ...
> > > > - q = p;
> > > > - x = *q;
> > > > -
> > > > -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
> > > > -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
> > > > -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
> > > > -업데이트 되어버렸을 수 있기 때문입니다.
> > > > -
> > > > - CPU 1 CPU 2 COMMENT
> > > > - =============== =============== =======================================
> > > > - u == 0, v == 1 and p == &u, q == &u
> > > > - v = 2;
> > > > - smp_wmb();
> > > > - <A:modify v=2> <C:busy>
> > > > - <C:queue v=2>
> > > > - p = &v; q = p;
> > > > - <D:request p>
> > > > - <B:modify p=&v> <D:commit p=&v>
> > > > - <D:read p>
> > > > - x = *q;
> > > > - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
> > > > - <C:unbusy>
> > > > - <C:commit v=2>
> > > > -
> > > > -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
> > > > -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
> > > > -것이라는 보장이 없습니다.
> > > > -
> > > > -
> > > > -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
> > > > -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
> > > > -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
> > > > -처리하도록 강제하게 됩니다.
> > > > -
> > > > - CPU 1 CPU 2 COMMENT
> > > > - =============== =============== =======================================
> > > > - u == 0, v == 1 and p == &u, q == &u
> > > > - v = 2;
> > > > - smp_wmb();
> > > > - <A:modify v=2> <C:busy>
> > > > - <C:queue v=2>
> > > > - p = &v; q = p;
> > > > - <D:request p>
> > > > - <B:modify p=&v> <D:commit p=&v>
> > > > - <D:read p>
> > > > - smp_read_barrier_depends()
> > > > - <C:unbusy>
> > > > - <C:commit v=2>
> > > > - x = *q;
> > > > - <C:read *q> 캐시에 업데이트 된 v 를 읽음
> > > > -
> > > > -
> > > > -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
> > > > -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
> > > > -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
> > > > -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
> > > > -아니기 때문에 이점에 의존해선 안됩니다.
> > > > -
> > > > -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
> > > > -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
> > > > -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
> > > > -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
> > > > -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
> > > > -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
> > > > -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
> > > > -
> > > > -
> > > > 캐시 일관성 VS DMA
> > > > ------------------
> > > >
> > > > @@ -2959,10 +2821,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
> > > > 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
> > > >
> > > > 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
> > > > -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
> > > > -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
> > > > -
> > > > -위의 "캐시 일관성" 서브섹션을 참고하세요.
> > > > +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
> > > > +Alpha 의 영향력이 크게 줄어들었습니다.
> > > >
> > > >
> > > > 가상 머신 게스트
> > > > --
> > > > 2.17.2
> > > >
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-06 22:08 ` Paul E. McKenney
@ 2019-12-06 22:38 ` SeongJae Park
2019-12-06 22:51 ` Paul E. McKenney
0 siblings, 1 reply; 35+ messages in thread
From: SeongJae Park @ 2019-12-06 22:38 UTC (permalink / raw)
To: Paul E. McKenney, Jonathan Corbet, Will Deacon
Cc: LKML, linux-doc, notify, SeongJae Park
On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Fri, Dec 06, 2019 at 10:29:50PM +0100, SeongJae Park wrote:
> > On Fri, Dec 6, 2019 at 9:44 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> > >
> > > On Fri, Dec 06, 2019 at 06:20:51PM +0100, SeongJae Park wrote:
> > > > Hello Paul and Will,
> > > >
> > > > On Fri, Nov 29, 2019 at 7:09 PM SeongJae Park <sj38.park@gmail.com> wrote:
> > > > >
> > > > > Paul, thank you for waiting long. I got reviewed by another Korean
> > > > > hacker, Yunjae.
> > > > >
> > > > > Changes from v1 (https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/)
> > > > > - Get a review from Yunjae
> > > > > - Minor wordsmith based on the review comment
> > > > > - Rebased on git://git.lwn.net/linux.git tags/docs-5.5
> > > > > - Update author's email address
> > > >
> > > > May I ask your comments?
> > >
> > > I thought that Jon Corbet had already queued these. Did I miss some?
> >
> > This patch has not queued by Jon, indeed. I haven't CC-ed neither Jon, nor
> > linux-doc for the 1st version of this patch because this is a followup of
> > Will's patch[1] and the Will's patch also have not CC-ed them.
> >
> > I sent another patchset[2] for documents simultaneously but CC-ed Jon and
> > linux-doc for the patch, because the patchset is a followup of the commits
> > which already merged in Torvalds's tree. The patchset has queued by both of
> > you and then you agreed to merge it by Jon's tree. I guess I made the
> > confusion in this way. Sorry for making such confusion. Anyway, this patch
> > is not queued in any tree, AFIK.
>
> Not a problem at all!
That's a relief!
>
> But since Jon seems to be taking these in his capacity and Documentation
> maintainer, could you please resend CCing him? If we have these changes
> scattered across too many trees, someone is going to get confused,
> and it probably will be me. ;-)
Agreed, CC-ing Jon to this mail. That said, this is a followup of Will's
patch[1] and the patch is also not queued in Jon's tree. So, I would like to
hear Will's opinion either, if possible.
[1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
Thanks,
SeongJae Park
>
> Thanx, Paul
>
> > Thanks,
> > SeongJae Park
> >
> >
> > [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
> > [2] https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@gmail.com/
> >
> > >
> > > Thanx, Paul
> > >
> > > > Thanks,
> > > > SeongJae Park
> > > >
> > > > >
> > > > > --------------------------------- >8 -----------------------------------------
> > > > >
> > > > > This commit translates commit 8088616d4ca6 ("Documentation/barriers:
> > > > > Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
> > > > > into Korean.
> > > > >
> > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
> > > > >
> > > > > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > > > > Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> > > > >
> > > > > ---
> > > > > .../translations/ko_KR/memory-barriers.txt | 146 +-----------------
> > > > > 1 file changed, 3 insertions(+), 143 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> > > > > index f07c40a068b5..a8d26df9360b 100644
> > > > > --- a/Documentation/translations/ko_KR/memory-barriers.txt
> > > > > +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> > > > > @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
> > > > > 데이터 의존성 배리어 (역사적)
> > > > > -----------------------------
> > > > >
> > > > > -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
> > > > > +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
> > > > > 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
> > > > > 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
> > > > > 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
> > > > > @@ -2661,144 +2661,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
> > > > > 수도 있습니다.
> > > > >
> > > > >
> > > > > -캐시 일관성
> > > > > ------------
> > > > > -
> > > > > -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
> > > > > -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
> > > > > -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
> > > > > -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
> > > > > -
> > > > > -
> > > > > -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
> > > > > -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
> > > > > -봅시다:
> > > > > -
> > > > > - :
> > > > > - : +--------+
> > > > > - : +---------+ | |
> > > > > - +--------+ : +--->| Cache A |<------->| |
> > > > > - | | : | +---------+ | |
> > > > > - | CPU 1 |<---+ | |
> > > > > - | | : | +---------+ | |
> > > > > - +--------+ : +--->| Cache B |<------->| |
> > > > > - : +---------+ | |
> > > > > - : | Memory |
> > > > > - : +---------+ | System |
> > > > > - +--------+ : +--->| Cache C |<------->| |
> > > > > - | | : | +---------+ | |
> > > > > - | CPU 2 |<---+ | |
> > > > > - | | : | +---------+ | |
> > > > > - +--------+ : +--->| Cache D |<------->| |
> > > > > - : +---------+ | |
> > > > > - : +--------+
> > > > > - :
> > > > > -
> > > > > -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
> > > > > -
> > > > > - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
> > > > > -
> > > > > - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
> > > > > -
> > > > > - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
> > > > > - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
> > > > > - 액세스 하기 위해 버스를 사용할 수 있음;
> > > > > -
> > > > > - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
> > > > > - 적용되어야 할 오퍼레이션들의 큐를 가짐;
> > > > > -
> > > > > - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
> > > > > - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
> > > > > - 할지라도 그러함.
> > > > > -
> > > > > -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
> > > > > -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
> > > > > -배리어를 사용하는 상황을 상상해 봅시다:
> > > > > -
> > > > > - CPU 1 CPU 2 COMMENT
> > > > > - =============== =============== =======================================
> > > > > - u == 0, v == 1 and p == &u, q == &u
> > > > > - v = 2;
> > > > > - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
> > > > > - 분명히 함
> > > > > - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
> > > > > - p = &v;
> > > > > - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
> > > > > -
> > > > > -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
> > > > > -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
> > > > > -읽으려 하는 상황을 생각해 봅시다:
> > > > > -
> > > > > - CPU 1 CPU 2 COMMENT
> > > > > - =============== =============== =======================================
> > > > > - ...
> > > > > - q = p;
> > > > > - x = *q;
> > > > > -
> > > > > -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
> > > > > -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
> > > > > -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
> > > > > -업데이트 되어버렸을 수 있기 때문입니다.
> > > > > -
> > > > > - CPU 1 CPU 2 COMMENT
> > > > > - =============== =============== =======================================
> > > > > - u == 0, v == 1 and p == &u, q == &u
> > > > > - v = 2;
> > > > > - smp_wmb();
> > > > > - <A:modify v=2> <C:busy>
> > > > > - <C:queue v=2>
> > > > > - p = &v; q = p;
> > > > > - <D:request p>
> > > > > - <B:modify p=&v> <D:commit p=&v>
> > > > > - <D:read p>
> > > > > - x = *q;
> > > > > - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
> > > > > - <C:unbusy>
> > > > > - <C:commit v=2>
> > > > > -
> > > > > -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
> > > > > -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
> > > > > -것이라는 보장이 없습니다.
> > > > > -
> > > > > -
> > > > > -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
> > > > > -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
> > > > > -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
> > > > > -처리하도록 강제하게 됩니다.
> > > > > -
> > > > > - CPU 1 CPU 2 COMMENT
> > > > > - =============== =============== =======================================
> > > > > - u == 0, v == 1 and p == &u, q == &u
> > > > > - v = 2;
> > > > > - smp_wmb();
> > > > > - <A:modify v=2> <C:busy>
> > > > > - <C:queue v=2>
> > > > > - p = &v; q = p;
> > > > > - <D:request p>
> > > > > - <B:modify p=&v> <D:commit p=&v>
> > > > > - <D:read p>
> > > > > - smp_read_barrier_depends()
> > > > > - <C:unbusy>
> > > > > - <C:commit v=2>
> > > > > - x = *q;
> > > > > - <C:read *q> 캐시에 업데이트 된 v 를 읽음
> > > > > -
> > > > > -
> > > > > -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
> > > > > -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
> > > > > -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
> > > > > -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
> > > > > -아니기 때문에 이점에 의존해선 안됩니다.
> > > > > -
> > > > > -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
> > > > > -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
> > > > > -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
> > > > > -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
> > > > > -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
> > > > > -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
> > > > > -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
> > > > > -
> > > > > -
> > > > > 캐시 일관성 VS DMA
> > > > > ------------------
> > > > >
> > > > > @@ -2959,10 +2821,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
> > > > > 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
> > > > >
> > > > > 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
> > > > > -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
> > > > > -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
> > > > > -
> > > > > -위의 "캐시 일관성" 서브섹션을 참고하세요.
> > > > > +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
> > > > > +Alpha 의 영향력이 크게 줄어들었습니다.
> > > > >
> > > > >
> > > > > 가상 머신 게스트
> > > > > --
> > > > > 2.17.2
> > > > >
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-06 22:38 ` SeongJae Park
@ 2019-12-06 22:51 ` Paul E. McKenney
2019-12-09 9:44 ` Will Deacon
0 siblings, 1 reply; 35+ messages in thread
From: Paul E. McKenney @ 2019-12-06 22:51 UTC (permalink / raw)
To: SeongJae Park
Cc: Jonathan Corbet, Will Deacon, LKML, linux-doc, notify, SeongJae Park
On Fri, Dec 06, 2019 at 11:38:22PM +0100, SeongJae Park wrote:
> On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Fri, Dec 06, 2019 at 10:29:50PM +0100, SeongJae Park wrote:
> > > On Fri, Dec 6, 2019 at 9:44 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> > > >
> > > > On Fri, Dec 06, 2019 at 06:20:51PM +0100, SeongJae Park wrote:
> > > > > Hello Paul and Will,
> > > > >
> > > > > On Fri, Nov 29, 2019 at 7:09 PM SeongJae Park <sj38.park@gmail.com> wrote:
> > > > > >
> > > > > > Paul, thank you for waiting long. I got reviewed by another Korean
> > > > > > hacker, Yunjae.
> > > > > >
> > > > > > Changes from v1 (https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/)
> > > > > > - Get a review from Yunjae
> > > > > > - Minor wordsmith based on the review comment
> > > > > > - Rebased on git://git.lwn.net/linux.git tags/docs-5.5
> > > > > > - Update author's email address
> > > > >
> > > > > May I ask your comments?
> > > >
> > > > I thought that Jon Corbet had already queued these. Did I miss some?
> > >
> > > This patch has not queued by Jon, indeed. I haven't CC-ed neither Jon, nor
> > > linux-doc for the 1st version of this patch because this is a followup of
> > > Will's patch[1] and the Will's patch also have not CC-ed them.
> > >
> > > I sent another patchset[2] for documents simultaneously but CC-ed Jon and
> > > linux-doc for the patch, because the patchset is a followup of the commits
> > > which already merged in Torvalds's tree. The patchset has queued by both of
> > > you and then you agreed to merge it by Jon's tree. I guess I made the
> > > confusion in this way. Sorry for making such confusion. Anyway, this patch
> > > is not queued in any tree, AFIK.
> >
> > Not a problem at all!
>
> That's a relief!
>
> >
> > But since Jon seems to be taking these in his capacity and Documentation
> > maintainer, could you please resend CCing him? If we have these changes
> > scattered across too many trees, someone is going to get confused,
> > and it probably will be me. ;-)
>
> Agreed, CC-ing Jon to this mail. That said, this is a followup of Will's
> patch[1] and the patch is also not queued in Jon's tree. So, I would like to
> hear Will's opinion either, if possible.
>
> [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
Ah, this one got caught out in the conversion from .html to .rst.
I did get an ack on one of those, and thus queued it. I clearly need to
take another look at Will's series, and thank you for the reminder!
Thanx, Paul
> Thanks,
> SeongJae Park
>
> >
> > Thanx, Paul
> >
> > > Thanks,
> > > SeongJae Park
> > >
> > >
> > > [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
> > > [2] https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@gmail.com/
> > >
> > > >
> > > > Thanx, Paul
> > > >
> > > > > Thanks,
> > > > > SeongJae Park
> > > > >
> > > > > >
> > > > > > --------------------------------- >8 -----------------------------------------
> > > > > >
> > > > > > This commit translates commit 8088616d4ca6 ("Documentation/barriers:
> > > > > > Remove references to [smp_]read_barrier_depends()") of Will's tree[1]
> > > > > > into Korean.
> > > > > >
> > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/Documentation/memory-barriers.txt?h=lto&id=8088616d4ca61cd6b770225f30fec66c6f6767fb
> > > > > >
> > > > > > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > > > > > Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> > > > > >
> > > > > > ---
> > > > > > .../translations/ko_KR/memory-barriers.txt | 146 +-----------------
> > > > > > 1 file changed, 3 insertions(+), 143 deletions(-)
> > > > > >
> > > > > > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> > > > > > index f07c40a068b5..a8d26df9360b 100644
> > > > > > --- a/Documentation/translations/ko_KR/memory-barriers.txt
> > > > > > +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> > > > > > @@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
> > > > > > 데이터 의존성 배리어 (역사적)
> > > > > > -----------------------------
> > > > > >
> > > > > > -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
> > > > > > +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
> > > > > > 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
> > > > > > 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
> > > > > > 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
> > > > > > @@ -2661,144 +2661,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면
> > > > > > 수도 있습니다.
> > > > > >
> > > > > >
> > > > > > -캐시 일관성
> > > > > > ------------
> > > > > > -
> > > > > > -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
> > > > > > -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서
> > > > > > -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
> > > > > > -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
> > > > > > -
> > > > > > -
> > > > > > -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
> > > > > > -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
> > > > > > -봅시다:
> > > > > > -
> > > > > > - :
> > > > > > - : +--------+
> > > > > > - : +---------+ | |
> > > > > > - +--------+ : +--->| Cache A |<------->| |
> > > > > > - | | : | +---------+ | |
> > > > > > - | CPU 1 |<---+ | |
> > > > > > - | | : | +---------+ | |
> > > > > > - +--------+ : +--->| Cache B |<------->| |
> > > > > > - : +---------+ | |
> > > > > > - : | Memory |
> > > > > > - : +---------+ | System |
> > > > > > - +--------+ : +--->| Cache C |<------->| |
> > > > > > - | | : | +---------+ | |
> > > > > > - | CPU 2 |<---+ | |
> > > > > > - | | : | +---------+ | |
> > > > > > - +--------+ : +--->| Cache D |<------->| |
> > > > > > - : +---------+ | |
> > > > > > - : +--------+
> > > > > > - :
> > > > > > -
> > > > > > -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
> > > > > > -
> > > > > > - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
> > > > > > -
> > > > > > - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
> > > > > > -
> > > > > > - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
> > > > > > - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
> > > > > > - 액세스 하기 위해 버스를 사용할 수 있음;
> > > > > > -
> > > > > > - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
> > > > > > - 적용되어야 할 오퍼레이션들의 큐를 가짐;
> > > > > > -
> > > > > > - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
> > > > > > - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
> > > > > > - 할지라도 그러함.
> > > > > > -
> > > > > > -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
> > > > > > -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
> > > > > > -배리어를 사용하는 상황을 상상해 봅시다:
> > > > > > -
> > > > > > - CPU 1 CPU 2 COMMENT
> > > > > > - =============== =============== =======================================
> > > > > > - u == 0, v == 1 and p == &u, q == &u
> > > > > > - v = 2;
> > > > > > - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을
> > > > > > - 분명히 함
> > > > > > - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함
> > > > > > - p = &v;
> > > > > > - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함
> > > > > > -
> > > > > > -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
> > > > > > -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을
> > > > > > -읽으려 하는 상황을 생각해 봅시다:
> > > > > > -
> > > > > > - CPU 1 CPU 2 COMMENT
> > > > > > - =============== =============== =======================================
> > > > > > - ...
> > > > > > - q = p;
> > > > > > - x = *q;
> > > > > > -
> > > > > > -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
> > > > > > -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
> > > > > > -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
> > > > > > -업데이트 되어버렸을 수 있기 때문입니다.
> > > > > > -
> > > > > > - CPU 1 CPU 2 COMMENT
> > > > > > - =============== =============== =======================================
> > > > > > - u == 0, v == 1 and p == &u, q == &u
> > > > > > - v = 2;
> > > > > > - smp_wmb();
> > > > > > - <A:modify v=2> <C:busy>
> > > > > > - <C:queue v=2>
> > > > > > - p = &v; q = p;
> > > > > > - <D:request p>
> > > > > > - <B:modify p=&v> <D:commit p=&v>
> > > > > > - <D:read p>
> > > > > > - x = *q;
> > > > > > - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음
> > > > > > - <C:unbusy>
> > > > > > - <C:commit v=2>
> > > > > > -
> > > > > > -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
> > > > > > -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
> > > > > > -것이라는 보장이 없습니다.
> > > > > > -
> > > > > > -
> > > > > > -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
> > > > > > -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
> > > > > > -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
> > > > > > -처리하도록 강제하게 됩니다.
> > > > > > -
> > > > > > - CPU 1 CPU 2 COMMENT
> > > > > > - =============== =============== =======================================
> > > > > > - u == 0, v == 1 and p == &u, q == &u
> > > > > > - v = 2;
> > > > > > - smp_wmb();
> > > > > > - <A:modify v=2> <C:busy>
> > > > > > - <C:queue v=2>
> > > > > > - p = &v; q = p;
> > > > > > - <D:request p>
> > > > > > - <B:modify p=&v> <D:commit p=&v>
> > > > > > - <D:read p>
> > > > > > - smp_read_barrier_depends()
> > > > > > - <C:unbusy>
> > > > > > - <C:commit v=2>
> > > > > > - x = *q;
> > > > > > - <C:read *q> 캐시에 업데이트 된 v 를 읽음
> > > > > > -
> > > > > > -
> > > > > > -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은
> > > > > > -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기
> > > > > > -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기
> > > > > > -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건
> > > > > > -아니기 때문에 이점에 의존해선 안됩니다.
> > > > > > -
> > > > > > -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리
> > > > > > -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장
> > > > > > -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로
> > > > > > -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에
> > > > > > -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15
> > > > > > -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는
> > > > > > -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다.
> > > > > > -
> > > > > > -
> > > > > > 캐시 일관성 VS DMA
> > > > > > ------------------
> > > > > >
> > > > > > @@ -2959,10 +2821,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서
> > > > > > 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다.
> > > > > >
> > > > > > 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15
> > > > > > -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서
> > > > > > -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다.
> > > > > > -
> > > > > > -위의 "캐시 일관성" 서브섹션을 참고하세요.
> > > > > > +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의
> > > > > > +Alpha 의 영향력이 크게 줄어들었습니다.
> > > > > >
> > > > > >
> > > > > > 가상 머신 게스트
> > > > > > --
> > > > > > 2.17.2
> > > > > >
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-06 22:51 ` Paul E. McKenney
@ 2019-12-09 9:44 ` Will Deacon
2019-12-09 17:00 ` Paul E. McKenney
0 siblings, 1 reply; 35+ messages in thread
From: Will Deacon @ 2019-12-09 9:44 UTC (permalink / raw)
To: Paul E. McKenney
Cc: SeongJae Park, Jonathan Corbet, LKML, linux-doc, notify, SeongJae Park
On Fri, Dec 06, 2019 at 02:51:56PM -0800, Paul E. McKenney wrote:
> On Fri, Dec 06, 2019 at 11:38:22PM +0100, SeongJae Park wrote:
> > On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> > > But since Jon seems to be taking these in his capacity and Documentation
> > > maintainer, could you please resend CCing him? If we have these changes
> > > scattered across too many trees, someone is going to get confused,
> > > and it probably will be me. ;-)
> >
> > Agreed, CC-ing Jon to this mail. That said, this is a followup of Will's
> > patch[1] and the patch is also not queued in Jon's tree. So, I would like to
> > hear Will's opinion either, if possible.
> >
> > [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
>
> Ah, this one got caught out in the conversion from .html to .rst.
>
> I did get an ack on one of those, and thus queued it. I clearly need to
> take another look at Will's series, and thank you for the reminder!
I was planning to include this in the next posting of my series, but I was
waiting for the merge window to close first. Now that we have -rc1, I'll
post it this week, although the patches are also queued up in my tree here
[1] (warning -- rebasing development branch).
I'll leave the patches that are unrelated to smp_read_barrier_depends() to
Paul and Jon, unless they indicate a preference to the contrary.
Will
[1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-09 9:44 ` Will Deacon
@ 2019-12-09 17:00 ` Paul E. McKenney
2019-12-09 17:06 ` Will Deacon
0 siblings, 1 reply; 35+ messages in thread
From: Paul E. McKenney @ 2019-12-09 17:00 UTC (permalink / raw)
To: Will Deacon
Cc: SeongJae Park, Jonathan Corbet, LKML, linux-doc, notify, SeongJae Park
On Mon, Dec 09, 2019 at 09:44:33AM +0000, Will Deacon wrote:
> On Fri, Dec 06, 2019 at 02:51:56PM -0800, Paul E. McKenney wrote:
> > On Fri, Dec 06, 2019 at 11:38:22PM +0100, SeongJae Park wrote:
> > > On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> > > > But since Jon seems to be taking these in his capacity and Documentation
> > > > maintainer, could you please resend CCing him? If we have these changes
> > > > scattered across too many trees, someone is going to get confused,
> > > > and it probably will be me. ;-)
> > >
> > > Agreed, CC-ing Jon to this mail. That said, this is a followup of Will's
> > > patch[1] and the patch is also not queued in Jon's tree. So, I would like to
> > > hear Will's opinion either, if possible.
> > >
> > > [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
> >
> > Ah, this one got caught out in the conversion from .html to .rst.
> >
> > I did get an ack on one of those, and thus queued it. I clearly need to
> > take another look at Will's series, and thank you for the reminder!
>
> I was planning to include this in the next posting of my series, but I was
> waiting for the merge window to close first. Now that we have -rc1, I'll
> post it this week, although the patches are also queued up in my tree here
> [1] (warning -- rebasing development branch).
>
> I'll leave the patches that are unrelated to smp_read_barrier_depends() to
> Paul and Jon, unless they indicate a preference to the contrary.
I don't know about Jon, but I might need a reminder as to which patches
those are. ;-)
Thanx, Paul
> Will
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=lto
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-09 17:00 ` Paul E. McKenney
@ 2019-12-09 17:06 ` Will Deacon
2019-12-09 17:43 ` SeongJae Park
0 siblings, 1 reply; 35+ messages in thread
From: Will Deacon @ 2019-12-09 17:06 UTC (permalink / raw)
To: Paul E. McKenney
Cc: SeongJae Park, Jonathan Corbet, LKML, linux-doc, notify, SeongJae Park
On Mon, Dec 09, 2019 at 09:00:57AM -0800, Paul E. McKenney wrote:
> On Mon, Dec 09, 2019 at 09:44:33AM +0000, Will Deacon wrote:
> > On Fri, Dec 06, 2019 at 02:51:56PM -0800, Paul E. McKenney wrote:
> > > On Fri, Dec 06, 2019 at 11:38:22PM +0100, SeongJae Park wrote:
> > > > On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@kernel.org> wrote:
> > > > > But since Jon seems to be taking these in his capacity and Documentation
> > > > > maintainer, could you please resend CCing him? If we have these changes
> > > > > scattered across too many trees, someone is going to get confused,
> > > > > and it probably will be me. ;-)
> > > >
> > > > Agreed, CC-ing Jon to this mail. That said, this is a followup of Will's
> > > > patch[1] and the patch is also not queued in Jon's tree. So, I would like to
> > > > hear Will's opinion either, if possible.
> > > >
> > > > [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
> > >
> > > Ah, this one got caught out in the conversion from .html to .rst.
> > >
> > > I did get an ack on one of those, and thus queued it. I clearly need to
> > > take another look at Will's series, and thank you for the reminder!
> >
> > I was planning to include this in the next posting of my series, but I was
> > waiting for the merge window to close first. Now that we have -rc1, I'll
> > post it this week, although the patches are also queued up in my tree here
> > [1] (warning -- rebasing development branch).
> >
> > I'll leave the patches that are unrelated to smp_read_barrier_depends() to
> > Paul and Jon, unless they indicate a preference to the contrary.
>
> I don't know about Jon, but I might need a reminder as to which patches
> those are. ;-)
https://lore.kernel.org/lkml/20191121234125.28032-1-sj38.park@gmail.com
...but it actually looks like Jon picked those all up, so I think we're good.
SeongJae -- please shout if we've missed something (the link above, plus
this patch).
Will
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Re: [PATCH v2] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()
2019-12-09 17:06 ` Will Deacon
@ 2019-12-09 17:43 ` SeongJae Park
0 siblings, 0 replies; 35+ messages in thread
From: SeongJae Park @ 2019-12-09 17:43 UTC (permalink / raw)
To: will
Cc: SeongJae Park, Jonathan Corbet, LKML, linux-doc, notify, SeongJae Park
On Mon, 9 Dec 2019 17:06:34 +0000 Will Deacon <will@kernel.org> wrote:
>On Mon, Dec 09, 2019 at 09:00:57AM -0800, Paul E. McKenney wrote:
>> On Mon, Dec 09, 2019 at 09:44:33AM +0000, Will Deacon wrote:
>> > On Fri, Dec 06, 2019 at 02:51:56PM -0800, Paul E. McKenney wrote:
>> > > On Fri, Dec 06, 2019 at 11:38:22PM +0100, SeongJae Park wrote:
>> > > > On Fri, Dec 6, 2019 at 11:08 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>> > > > > But since Jon seems to be taking these in his capacity and Documentation
>> > > > > maintainer, could you please resend CCing him? If we have these changes
>> > > > > scattered across too many trees, someone is going to get confused,
>> > > > > and it probably will be me. ;-)
>> > > >
>> > > > Agreed, CC-ing Jon to this mail. That said, this is a followup of Will's
>> > > > patch[1] and the patch is also not queued in Jon's tree. So, I would like to
>> > > > hear Will's opinion either, if possible.
>> > > >
>> > > > [1] https://lore.kernel.org/lkml/20191108170120.22331-10-will@kernel.org/
>> > >
>> > > Ah, this one got caught out in the conversion from .html to .rst.
>> > >
>> > > I did get an ack on one of those, and thus queued it. I clearly need to
>> > > take another look at Will's series, and thank you for the reminder!
>> >
>> > I was planning to include this in the next posting of my series, but I was
>> > waiting for the merge window to close first. Now that we have -rc1, I'll
>> > post it this week, although the patches are also queued up in my tree here
>> > [1] (warning -- rebasing development branch).
>> >
>> > I'll leave the patches that are unrelated to smp_read_barrier_depends() to
>> > Paul and Jon, unless they indicate a preference to the contrary.
>>
>> I don't know about Jon, but I might need a reminder as to which patches
>> those are. ;-)
>
>https://lore.kernel.org/lkml/20191121234125.28032-1-sj38.park@gmail.com
>
>...but it actually looks like Jon picked those all up, so I think we're good.
>
>SeongJae -- please shout if we've missed something (the link above, plus
>this patch).
Sorry for making things too complicated. So, below is the timeline:
2019-11-08
----------
Will posted a patchset containing a patch removing references to
[smp_]read_barrier_depends() from memory-barriers.txt.
https://lore.kernel.org/lkml/20191108170120.22331-1-will@kernel.org/
2019-11-21
----------
I posted a translation of the patch (patchset 1):
https://lore.kernel.org/lkml/20191121193209.15687-1-sj38.park@gmail.com/
2019-11-22
----------
I posted another patchset for the Korean translations (patchset 2):
https://lore.kernel.org/linux-doc/20191121234125.28032-1-sj38.park@gmail.com/
2019-11-26
----------
Paul queued the `patchset 1` and `patchset 2`. He also asked me to
get a review from other Korean, if possible:
https://lore.kernel.org/lkml/20191126222004.GV2889@paulmck-ThinkPad-P72/
Same day, Jon queued the `patchset 2` (not `patchset 1`) and noticed the
conflict. Paul dropped both `patchset 1` and `patchset 2` from his tree.
Maybe this is the start of the confusion.
2019-11-29
----------
I got a review results from another Korean for both patchset 1 and patchset 2.
Because patchset 1 has already merged in Linus's tree, I made another patchset
containing fix of the patchset 1 (patchset 1-1):
https://lore.kernel.org/linux-doc/20191129182823.8710-1-sjpark@amazon.de/
Because patchset 2 is not merged in any tree, I made and posted the second
version of the patchset 2 (patchset 2-1):
https://lore.kernel.org/lkml/20191129180837.7233-1-sjpark@amazon.de/
So, patchset 1 is already merged by Jon, and patchset 2 is abandoned.
Patchset 1-1 is waiting for Jon's review, and patchset 2-1 is merged in Will's
tree. Will would send the patchset 2-1 with his patches again in near future.
Sorry again for introducing messy confusion and hope this to finally make
things clear. If you have any problem, please let me know.
>
>Will
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends() from informal doc
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (8 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 09/13] Documentation/barriers: Remove references to [smp_]read_barrier_depends() Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:42 ` Alan Stern
2019-11-08 17:01 ` [PATCH 11/13] powerpc: Remove comment about read_barrier_depends() Will Deacon
` (3 subsequent siblings)
13 siblings, 1 reply; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
'smp_read_barrier_depends()' has gone the way of mmiowb() and so many
esoteric memory barriers before it. Drop the two mentions of this
deceased barrier from the LKMM informal explanation document.
Signed-off-by: Will Deacon <will@kernel.org>
---
.../Documentation/explanation.txt | 26 +++++++++----------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt
index 488f11f6c588..3050bf67b8d0 100644
--- a/tools/memory-model/Documentation/explanation.txt
+++ b/tools/memory-model/Documentation/explanation.txt
@@ -1118,12 +1118,10 @@ maintain at least the appearance of FIFO order.
In practice, this difficulty is solved by inserting a special fence
between P1's two loads when the kernel is compiled for the Alpha
architecture. In fact, as of version 4.15, the kernel automatically
-adds this fence (called smp_read_barrier_depends() and defined as
-nothing at all on non-Alpha builds) after every READ_ONCE() and atomic
-load. The effect of the fence is to cause the CPU not to execute any
-po-later instructions until after the local cache has finished
-processing all the stores it has already received. Thus, if the code
-was changed to:
+adds this fence after every READ_ONCE() and atomic load on Alpha. The
+effect of the fence is to cause the CPU not to execute any po-later
+instructions until after the local cache has finished processing all
+the stores it has already received. Thus, if the code was changed to:
P1()
{
@@ -1142,14 +1140,14 @@ READ_ONCE() or another synchronization primitive rather than accessed
directly.
The LKMM requires that smp_rmb(), acquire fences, and strong fences
-share this property with smp_read_barrier_depends(): They do not allow
-the CPU to execute any po-later instructions (or po-later loads in the
-case of smp_rmb()) until all outstanding stores have been processed by
-the local cache. In the case of a strong fence, the CPU first has to
-wait for all of its po-earlier stores to propagate to every other CPU
-in the system; then it has to wait for the local cache to process all
-the stores received as of that time -- not just the stores received
-when the strong fence began.
+share this property: They do not allow the CPU to execute any po-later
+instructions (or po-later loads in the case of smp_rmb()) until all
+outstanding stores have been processed by the local cache. In the
+case of a strong fence, the CPU first has to wait for all of its
+po-earlier stores to propagate to every other CPU in the system; then
+it has to wait for the local cache to process all the stores received
+as of that time -- not just the stores received when the strong fence
+began.
And of course, none of this matters for any architecture other than
Alpha.
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* Re: [PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends() from informal doc
2019-11-08 17:01 ` [PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends() from informal doc Will Deacon
@ 2019-11-08 17:42 ` Alan Stern
0 siblings, 0 replies; 35+ messages in thread
From: Alan Stern @ 2019-11-08 17:42 UTC (permalink / raw)
To: Will Deacon
Cc: linux-kernel, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Michael Ellerman, Michael S. Tsirkin, Jason Wang,
Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
On Fri, 8 Nov 2019, Will Deacon wrote:
> 'smp_read_barrier_depends()' has gone the way of mmiowb() and so many
> esoteric memory barriers before it. Drop the two mentions of this
> deceased barrier from the LKMM informal explanation document.
>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> .../Documentation/explanation.txt | 26 +++++++++----------
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt
> index 488f11f6c588..3050bf67b8d0 100644
> --- a/tools/memory-model/Documentation/explanation.txt
> +++ b/tools/memory-model/Documentation/explanation.txt
> @@ -1118,12 +1118,10 @@ maintain at least the appearance of FIFO order.
> In practice, this difficulty is solved by inserting a special fence
> between P1's two loads when the kernel is compiled for the Alpha
> architecture. In fact, as of version 4.15, the kernel automatically
> -adds this fence (called smp_read_barrier_depends() and defined as
> -nothing at all on non-Alpha builds) after every READ_ONCE() and atomic
> -load. The effect of the fence is to cause the CPU not to execute any
> -po-later instructions until after the local cache has finished
> -processing all the stores it has already received. Thus, if the code
> -was changed to:
> +adds this fence after every READ_ONCE() and atomic load on Alpha. The
> +effect of the fence is to cause the CPU not to execute any po-later
> +instructions until after the local cache has finished processing all
> +the stores it has already received. Thus, if the code was changed to:
>
> P1()
> {
> @@ -1142,14 +1140,14 @@ READ_ONCE() or another synchronization primitive rather than accessed
> directly.
>
> The LKMM requires that smp_rmb(), acquire fences, and strong fences
> -share this property with smp_read_barrier_depends(): They do not allow
> -the CPU to execute any po-later instructions (or po-later loads in the
> -case of smp_rmb()) until all outstanding stores have been processed by
> -the local cache. In the case of a strong fence, the CPU first has to
> -wait for all of its po-earlier stores to propagate to every other CPU
> -in the system; then it has to wait for the local cache to process all
> -the stores received as of that time -- not just the stores received
> -when the strong fence began.
> +share this property: They do not allow the CPU to execute any po-later
> +instructions (or po-later loads in the case of smp_rmb()) until all
> +outstanding stores have been processed by the local cache. In the
> +case of a strong fence, the CPU first has to wait for all of its
> +po-earlier stores to propagate to every other CPU in the system; then
> +it has to wait for the local cache to process all the stores received
> +as of that time -- not just the stores received when the strong fence
> +began.
>
> And of course, none of this matters for any architecture other than
> Alpha.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 11/13] powerpc: Remove comment about read_barrier_depends()
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (9 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 10/13] tools/memory-model: Remove smp_read_barrier_depends() from informal doc Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-20 10:37 ` Michael Ellerman
2019-11-08 17:01 ` [PATCH 12/13] include/linux: Remove smp_read_barrier_depends() from comments Will Deacon
` (2 subsequent siblings)
13 siblings, 1 reply; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
'read_barrier_depends()' doesn't exist anymore so stop talking about it.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/powerpc/include/asm/barrier.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h
index fbe8df433019..123adcefd40f 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -18,8 +18,6 @@
* mb() prevents loads and stores being reordered across this point.
* rmb() prevents loads being reordered across this point.
* wmb() prevents stores being reordered across this point.
- * read_barrier_depends() prevents data-dependent loads being reordered
- * across this point (nop on PPC).
*
* *mb() variants without smp_ prefix must order all types of memory
* operations with one another. sync is the only instruction sufficient
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* Re: [PATCH 11/13] powerpc: Remove comment about read_barrier_depends()
2019-11-08 17:01 ` [PATCH 11/13] powerpc: Remove comment about read_barrier_depends() Will Deacon
@ 2019-11-20 10:37 ` Michael Ellerman
2019-11-26 22:24 ` Paul E. McKenney
0 siblings, 1 reply; 35+ messages in thread
From: Michael Ellerman @ 2019-11-20 10:37 UTC (permalink / raw)
To: Will Deacon, linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael S. Tsirkin, Jason Wang,
Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
Will Deacon <will@kernel.org> writes:
> 'read_barrier_depends()' doesn't exist anymore so stop talking about it.
>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/powerpc/include/asm/barrier.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h
> index fbe8df433019..123adcefd40f 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -18,8 +18,6 @@
> * mb() prevents loads and stores being reordered across this point.
> * rmb() prevents loads being reordered across this point.
> * wmb() prevents stores being reordered across this point.
> - * read_barrier_depends() prevents data-dependent loads being reordered
> - * across this point (nop on PPC).
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 11/13] powerpc: Remove comment about read_barrier_depends()
2019-11-20 10:37 ` Michael Ellerman
@ 2019-11-26 22:24 ` Paul E. McKenney
0 siblings, 0 replies; 35+ messages in thread
From: Paul E. McKenney @ 2019-11-26 22:24 UTC (permalink / raw)
To: Michael Ellerman
Cc: Will Deacon, linux-kernel, Yunjae Lee, SeongJae Park,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael S. Tsirkin, Jason Wang,
Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
On Wed, Nov 20, 2019 at 09:37:52PM +1100, Michael Ellerman wrote:
> Will Deacon <will@kernel.org> writes:
> > 'read_barrier_depends()' doesn't exist anymore so stop talking about it.
> >
> > Signed-off-by: Will Deacon <will@kernel.org>
> > ---
> > arch/powerpc/include/asm/barrier.h | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h
> > index fbe8df433019..123adcefd40f 100644
> > --- a/arch/powerpc/include/asm/barrier.h
> > +++ b/arch/powerpc/include/asm/barrier.h
> > @@ -18,8 +18,6 @@
> > * mb() prevents loads and stores being reordered across this point.
> > * rmb() prevents loads being reordered across this point.
> > * wmb() prevents stores being reordered across this point.
> > - * read_barrier_depends() prevents data-dependent loads being reordered
> > - * across this point (nop on PPC).
>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Queued for v5.6, thank you both!
Thanx, Paul
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 12/13] include/linux: Remove smp_read_barrier_depends() from comments
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (10 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 11/13] powerpc: Remove comment about read_barrier_depends() Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 17:01 ` [PATCH 13/13] checkpatch: Remove checks relating to [smp_]read_barrier_depends() Will Deacon
2019-11-08 18:50 ` [PATCH 00/13] Finish off [smp_]read_barrier_depends() Paul E. McKenney
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
'smp_read_barrier_depends()' doesn't exist any more, so reword the two
comments that mention it to refer to "dependency ordering" instead.
Signed-off-by: Will Deacon <will@kernel.org>
---
include/linux/percpu-refcount.h | 2 +-
include/linux/ptr_ring.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index 7aef0abc194a..246760b93715 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -155,7 +155,7 @@ static inline bool __ref_is_percpu(struct percpu_ref *ref,
* between contaminating the pointer value, meaning that
* READ_ONCE() is required when fetching it.
*
- * The smp_read_barrier_depends() implied by READ_ONCE() pairs
+ * The dependency ordering from the READ_ONCE() pairs
* with smp_store_release() in __percpu_ref_switch_to_percpu().
*/
percpu_ptr = READ_ONCE(ref->percpu_count_ptr);
diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 0abe9a4fc842..b6e94b60fc12 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -106,7 +106,7 @@ static inline int __ptr_ring_produce(struct ptr_ring *r, void *ptr)
return -ENOSPC;
/* Make sure the pointer we are storing points to a valid data. */
- /* Pairs with smp_read_barrier_depends in __ptr_ring_consume. */
+ /* Pairs with the dependency ordering in __ptr_ring_consume. */
smp_wmb();
WRITE_ONCE(r->queue[r->producer++], ptr);
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* [PATCH 13/13] checkpatch: Remove checks relating to [smp_]read_barrier_depends()
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (11 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 12/13] include/linux: Remove smp_read_barrier_depends() from comments Will Deacon
@ 2019-11-08 17:01 ` Will Deacon
2019-11-08 18:50 ` [PATCH 00/13] Finish off [smp_]read_barrier_depends() Paul E. McKenney
13 siblings, 0 replies; 35+ messages in thread
From: Will Deacon @ 2019-11-08 17:01 UTC (permalink / raw)
To: linux-kernel
Cc: Will Deacon, Yunjae Lee, SeongJae Park, Paul E. McKenney,
Josh Triplett, Matt Turner, Ivan Kokshaysky, Richard Henderson,
Peter Zijlstra, Alan Stern, Michael Ellerman, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
The '[smp_]read_barrier_depends()' macros no longer exist, so we don't
need to deal with them in the checkpatch script.
Signed-off-by: Will Deacon <will@kernel.org>
---
scripts/checkpatch.pl | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 6fcc66afb088..7f5a368206bf 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5787,8 +5787,7 @@ sub process {
my $barriers = qr{
mb|
rmb|
- wmb|
- read_barrier_depends
+ wmb
}x;
my $barrier_stems = qr{
mb__before_atomic|
@@ -5829,12 +5828,6 @@ sub process {
}
}
-# check for smp_read_barrier_depends and read_barrier_depends
- if (!$file && $line =~ /\b(smp_|)read_barrier_depends\s*\(/) {
- WARN("READ_BARRIER_DEPENDS",
- "$1read_barrier_depends should only be used in READ_ONCE or DEC Alpha code\n" . $herecurr);
- }
-
# check of hardware specific defines
if ($line =~ m@^.\s*\#\s*if.*\b(__i386__|__powerpc64__|__sun__|__s390x__)\b@ && $realfile !~ m@include/asm-@) {
CHK("ARCH_DEFINES",
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related [flat|nested] 35+ messages in thread* Re: [PATCH 00/13] Finish off [smp_]read_barrier_depends()
2019-11-08 17:01 [PATCH 00/13] Finish off [smp_]read_barrier_depends() Will Deacon
` (12 preceding siblings ...)
2019-11-08 17:01 ` [PATCH 13/13] checkpatch: Remove checks relating to [smp_]read_barrier_depends() Will Deacon
@ 2019-11-08 18:50 ` Paul E. McKenney
13 siblings, 0 replies; 35+ messages in thread
From: Paul E. McKenney @ 2019-11-08 18:50 UTC (permalink / raw)
To: Will Deacon
Cc: linux-kernel, Yunjae Lee, SeongJae Park, Josh Triplett,
Matt Turner, Ivan Kokshaysky, Richard Henderson, Peter Zijlstra,
Alan Stern, Michael Ellerman, Michael S. Tsirkin, Jason Wang,
Arnd Bergmann, Joe Perches, Boqun Feng, linux-alpha,
virtualization
On Fri, Nov 08, 2019 at 05:01:07PM +0000, Will Deacon wrote:
> Hi all,
>
> Although [smp_]read_barrier_depends() became part of READ_ONCE() in
> commit 76ebbe78f739 ("locking/barriers: Add implicit
> smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the
> Linux memory model with the sinister hope of attracting innocent new
> users so that it becomes impossible to remove altogether.
>
> Let's strike before it's too late: there's only one user outside of
> arch/alpha/ and that lives in the vhost code which I don't think you
> can actually compile for Alpha. Even if you could, it appears to be
> redundant. The rest of these patches remove any mention of the barrier
> from Documentation and comments, as well as removing its use from the
> Alpha backend and finally dropping it from the memory model completely.
>
> After this series, there are still two places where it is mentioned:
>
> 1. The Korean translation of memory-barriers.txt. I'd appreciate some
> help fixing this because it's not entirely a straightforward
> deletion.
>
> 2. The virtio vring tests under tools/. This is userspace code so I'm
> not too fussed about it.
>
> There's a chunk of header reshuffling at the start of the series so that
> READ_ONCE() can sensibly be overridden by arch code.
>
> Feedback welcome.
For the series:
Acked-by: Paul E. McKenney <paulmck@kernel.org>
> Cheers,
>
> Will
>
> Cc: Yunjae Lee <lyj7694@gmail.com>
> Cc: SeongJae Park <sj38.park@gmail.com>
> Cc: "Paul E. McKenney" <paulmck@kernel.org>
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Matt Turner <mattst88@gmail.com>
> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
> Cc: Richard Henderson <rth@twiddle.net>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Joe Perches <joe@perches.com>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: linux-alpha@vger.kernel.org
> Cc: virtualization@lists.linux-foundation.org
>
> --->8
>
> Will Deacon (13):
> compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
> READ_ONCE: Undefine internal __READ_ONCE_SIZE macro after use
> READ_ONCE: Allow __READ_ONCE_SIZE cases to be overridden by the
> architecture
> vhost: Remove redundant use of read_barrier_depends() barrier
> alpha: Override READ_ONCE() with barriered implementation
> READ_ONCE: Remove smp_read_barrier_depends() invocation
> alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb()
> locking/barriers: Remove definitions for [smp_]read_barrier_depends()
> Documentation/barriers: Remove references to
> [smp_]read_barrier_depends()
> tools/memory-model: Remove smp_read_barrier_depends() from informal
> doc
> powerpc: Remove comment about read_barrier_depends()
> include/linux: Remove smp_read_barrier_depends() from comments
> checkpatch: Remove checks relating to [smp_]read_barrier_depends()
>
> .../RCU/Design/Requirements/Requirements.html | 11 +-
> Documentation/memory-barriers.txt | 156 +-----------------
> arch/alpha/include/asm/atomic.h | 16 +-
> arch/alpha/include/asm/barrier.h | 61 +------
> arch/alpha/include/asm/pgtable.h | 10 +-
> arch/alpha/include/asm/rwonce.h | 22 +++
> arch/powerpc/include/asm/barrier.h | 2 -
> drivers/vhost/vhost.c | 5 -
> include/asm-generic/Kbuild | 1 +
> include/asm-generic/barrier.h | 17 --
> include/asm-generic/rwonce.h | 131 +++++++++++++++
> include/linux/compiler.h | 114 +------------
> include/linux/compiler_attributes.h | 12 ++
> include/linux/percpu-refcount.h | 2 +-
> include/linux/ptr_ring.h | 2 +-
> mm/memory.c | 2 +-
> scripts/checkpatch.pl | 9 +-
> .../Documentation/explanation.txt | 26 ++-
> 18 files changed, 217 insertions(+), 382 deletions(-)
> create mode 100644 arch/alpha/include/asm/rwonce.h
> create mode 100644 include/asm-generic/rwonce.h
>
> --
> 2.24.0.rc1.363.gb1bccd3e3d-goog
>
^ permalink raw reply [flat|nested] 35+ messages in thread