locktorture and memory-barriers.txt updates
cover locktorture and memory-barriers.txt updates
Hello!
This series contains a few memory-barriers.txt updates and a locktorture cleanup:
1. Add a disclaimer to memory-barrier.txt, courtesy of
Peter Zijlstra.
2. Explicitly state the purpose of memory-barrier.txt, courtesy
of David Howells.
3. Explicitly state that ACQUIRE applies to loads and that
RELEASE applies to stores, courtesy of Will Deacon.
4. Simplify torture_runnable computation in locktorture, replacing
a multiline #ifdef with an IS_ENABLED() that fits into an existing line.
Thanx, Paul
------------------------------------------------------------------------
Documentation/memory-barriers.txt | 39 +++++++++++++++++++++++++++++++++++++- kernel/locking/locktorture.c | 7 ------ 2 files changed, 39 insertions(+), 7 deletions(-)
PATCH 1/4 documentation: Add disclaimer
From: Peter Zijlstra <[email protected]>
It appears people are reading this document as a requirements list for building hardware. This is not the intent of this document. Nor is it particularly suited for this purpose.
The primary purpose of this document is our collective attempt to define a set of primitives that (hopefully) allow us to write correct code on the myriad of SMP platforms Linux supports.
Its a definite work in progress as our understanding of these platforms, and memory ordering in general, progresses.
Nor does being mentioned in this document mean we think its a particularly good idea; the data dependency barrier required by Alpha being a prime example. Yes we have it, no you're insane to require it when building new hardware.
--- Documentation/memory-barriers.txt | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
Documentation/memory-barriers.txt +17 -1
@@ -4,8 +4,24 @@ By: David Howells <[email protected]> Paul E. McKenney <[email protected]> + Will Deacon <[email protected]> + Peter Zijlstra <[email protected]> -Contents: +========== +DISCLAIMER +========== + +This document is not a specification; it is intentionally (for the sake of +brevity) and unintentionally (due to being human) incomplete. This document is +meant as a guide to using the various memory barriers provided by Linux, but +in case of any doubt (and there are many) please ask. + +To repeat, this document is not a specification of what Linux expects from +hardware. + +======== +CONTENTS +======== (*) Abstract memory access model.
Signature · 1 line
2.5.2
tip-bot for Peter Zijlstra
merge bot[tip:locking/core] locking/Documentation: Add disclaimer
locking/Documentation: Add disclaimer
Commit-ID: e7720af5f9ac914577e2b810d5c004cdf395fd82 Gitweb: http://git.kernel.org/tip/e7720af5f9ac914577e2b810d5c004cdf395fd82 Author: Peter Zijlstra <[email protected]> AuthorDate: Tue, 26 Apr 2016 10:22:05 -0700 Committer: Ingo Molnar <[email protected]> CommitDate: Thu, 28 Apr 2016 10:57:51 +0200
locking/Documentation: Add disclaimer
It appears people are reading this document as a requirements list for building hardware. This is not the intent of this document. Nor is it particularly suited for this purpose.
The primary purpose of this document is our collective attempt to define a set of primitives that (hopefully) allow us to write correct code on the myriad of SMP platforms Linux supports.
Its a definite work in progress as our understanding of these platforms, and memory ordering in general, progresses.
Nor does being mentioned in this document mean we think its a particularly good idea; the data dependency barrier required by Alpha being a prime example. Yes we have it, no you're insane to require it when building new hardware.
--- Documentation/memory-barriers.txt | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
Documentation/memory-barriers.txt +17 -1
@@ -4,8 +4,24 @@ By: David Howells <[email protected]> Paul E. McKenney <[email protected]> + Will Deacon <[email protected]> + Peter Zijlstra <[email protected]> -Contents: +========== +DISCLAIMER +========== + +This document is not a specification; it is intentionally (for the sake of +brevity) and unintentionally (due to being human) incomplete. This document is +meant as a guide to using the various memory barriers provided by Linux, but +in case of any doubt (and there are many) please ask. + +To repeat, this document is not a specification of what Linux expects from +hardware. + +======== +CONTENTS +======== (*) Abstract memory access model.
PATCH 2/4 documentation: State purpose of memory-barriers.txt
In reply to Paul E. McKenneyFrom: David Howells <[email protected]>
There has been some confusion about the purpose of memory-barriers.txt, so this commit adds a statement of purpose.
--- Documentation/memory-barriers.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Documentation/memory-barriers.txt +16 -0
@@ -19,6 +19,22 @@ in case of any doubt (and there are many) please ask. To repeat, this document is not a specification of what Linux expects from hardware. +The purpose of this document is twofold: + + (1) to specify the minimum functionality that one can rely on for any + particular barrier, and + + (2) to provide a guide as to how to use the barriers that are available. + +Note that an architecture can provide more than the minimum requirement +for any particular barrier, but if the architecure provides less than +that, that architecture is incorrect. + +Note also that it is possible that a barrier may be a no-op for an +architecture because the way that arch works renders an explicit barrier +unnecessary in that case. + + ======== CONTENTS ========
Signature · 1 line
2.5.2
tip-bot for David Howells
merge bot[tip:locking/core] locking/Documentation: State purpose of memory-barriers.txt
locking/Documentation: State purpose of memory-barriers.txt
Commit-ID: 8d4840e84871847ee1bae56a776907d08a9265f7 Gitweb: http://git.kernel.org/tip/8d4840e84871847ee1bae56a776907d08a9265f7 Author: David Howells <[email protected]> AuthorDate: Tue, 26 Apr 2016 10:22:06 -0700 Committer: Ingo Molnar <[email protected]> CommitDate: Thu, 28 Apr 2016 10:57:51 +0200
locking/Documentation: State purpose of memory-barriers.txt
There has been some confusion about the purpose of memory-barriers.txt, so this commit adds a statement of purpose.
--- Documentation/memory-barriers.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Documentation/memory-barriers.txt +16 -0
@@ -19,6 +19,22 @@ in case of any doubt (and there are many) please ask. To repeat, this document is not a specification of what Linux expects from hardware. +The purpose of this document is twofold: + + (1) to specify the minimum functionality that one can rely on for any + particular barrier, and + + (2) to provide a guide as to how to use the barriers that are available. + +Note that an architecture can provide more than the minimum requirement +for any particular barrier, but if the architecure provides less than +that, that architecture is incorrect. + +Note also that it is possible that a barrier may be a no-op for an +architecture because the way that arch works renders an explicit barrier +unnecessary in that case. + + ======== CONTENTS ========
PATCH 3/4 documentation: ACQUIRE applies to loads, RELEASE applies to stores
In reply to Paul E. McKenneyFrom: Will Deacon <[email protected]>
For compound atomics performing both a load and a store operation, make it clear that _acquire and _release variants refer only to the load and store portions of compound atomic. For example, xchg_acquire is an xchg operation where the load takes on ACQUIRE semantics.
--- Documentation/memory-barriers.txt | 5 +++++ 1 file changed, 5 insertions(+)
Documentation/memory-barriers.txt +5 -0
@@ -498,6 +498,11 @@ And a couple of implicit varieties: This means that ACQUIRE acts as a minimal "acquire" operation and RELEASE acts as a minimal "release" operation. +A subset of the atomic operations described in atomic_ops.txt have ACQUIRE +and RELEASE variants in addition to fully-ordered and relaxed (no barrier +semantics) definitions. For compound atomics performing both a load and a +store, ACQUIRE semantics apply only to the load and RELEASE semantics apply +only to the store portion of the operation. Memory barriers are only required where there's a possibility of interaction between two CPUs or between a CPU and a device. If it can be guaranteed that
Signature · 1 line
2.5.2
tip-bot for Will Deacon
merge bot[tip:locking/core] locking/Documentation: Clarify that ACQUIRE applies to loads, RELEASE applies to stores
locking/Documentation: Clarify that ACQUIRE applies to loads, RELEASE applies to stores
Commit-ID: 3cfe2e8bc1cf74d78df6fe5ca3a1e1805472a004 Gitweb: http://git.kernel.org/tip/3cfe2e8bc1cf74d78df6fe5ca3a1e1805472a004 Author: Will Deacon <[email protected]> AuthorDate: Tue, 26 Apr 2016 10:22:07 -0700 Committer: Ingo Molnar <[email protected]> CommitDate: Thu, 28 Apr 2016 10:57:51 +0200
locking/Documentation: Clarify that ACQUIRE applies to loads, RELEASE applies to stores
For compound atomics performing both a load and a store operation, make it clear that _acquire and _release variants refer only to the load and store portions of compound atomic. For example, xchg_acquire is an xchg operation where the load takes on ACQUIRE semantics.
--- Documentation/memory-barriers.txt | 5 +++++ 1 file changed, 5 insertions(+)
Documentation/memory-barriers.txt +5 -0
@@ -498,6 +498,11 @@ And a couple of implicit varieties: This means that ACQUIRE acts as a minimal "acquire" operation and RELEASE acts as a minimal "release" operation. +A subset of the atomic operations described in atomic_ops.txt have ACQUIRE +and RELEASE variants in addition to fully-ordered and relaxed (no barrier +semantics) definitions. For compound atomics performing both a load and a +store, ACQUIRE semantics apply only to the load and RELEASE semantics apply +only to the store portion of the operation. Memory barriers are only required where there's a possibility of interaction between two CPUs or between a CPU and a device. If it can be guaranteed that
PATCH 4/4 locktorture: Simplify torture_runnable computation
In reply to Paul E. McKenneyThis commit replaces a #ifdef with IS_ENABLED(), saving five lines.
--- kernel/locking/locktorture.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
kernel/locking/locktorture.c +1 -6
@@ -75,12 +75,7 @@ struct lock_stress_stats {long n_lock_acquired; }; -#if defined(MODULE ) -#define LOCKTORTURE_RUNNABLE_INIT 1 -#else -#define LOCKTORTURE_RUNNABLE_INIT 0 -#endif -int torture_runnable =LOCKTORTURE_RUNNABLE_INIT ; +int torture_runnable =IS_ENABLED (MODULE );module_param (torture_runnable, int,0444 );MODULE_PARM_DESC (torture_runnable,"Start locktorture at module init" );
Signature · 1 line
2.5.2
tip-bot for Paul E. McKenney
merge bot[tip:locking/core] lcoking/locktorture: Simplify the torture_runnable computation
lcoking/locktorture: Simplify the torture_runnable computation
Commit-ID: 5db4298133d99b3dfc60d6899ac9df169769c899 Gitweb: http://git.kernel.org/tip/5db4298133d99b3dfc60d6899ac9df169769c899 Author: Paul E. McKenney <[email protected]> AuthorDate: Tue, 26 Apr 2016 10:22:08 -0700 Committer: Ingo Molnar <[email protected]> CommitDate: Thu, 28 Apr 2016 10:57:51 +0200
lcoking/locktorture: Simplify the torture_runnable computation
This commit replaces an #ifdef with IS_ENABLED(), saving five lines.
--- kernel/locking/locktorture.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
kernel/locking/locktorture.c +1 -6
@@ -75,12 +75,7 @@ struct lock_stress_stats {long n_lock_acquired; }; -#if defined(MODULE ) -#define LOCKTORTURE_RUNNABLE_INIT 1 -#else -#define LOCKTORTURE_RUNNABLE_INIT 0 -#endif -int torture_runnable =LOCKTORTURE_RUNNABLE_INIT ; +int torture_runnable =IS_ENABLED (MODULE );module_param (torture_runnable, int,0444 );MODULE_PARM_DESC (torture_runnable,"Start locktorture at module init" );