Documentation changes for 3.17
Subsystems (3)
cover Documentation changes for 3.17
Hello!
This series provides a few documentation updates:
1. Clarify that if there is nothing awakened, then there is no
memory barrier.
2. Fix broken RTFP URL, courtesy of Pranith Kumar.
3. Add acquire/release barrier to memory-barrier pairing rules.
4. Add pointer to percpu-ref in rcuref.txt documentation.
Thanx, Paul
------------------------------------------------------------------------
b/Documentation/RCU/RTFP.txt | 4 ++-- b/Documentation/RCU/rcuref.txt | 9 +++++++++ b/Documentation/memory-barriers.txt | 25 +++++++++++++++++++++---- 3 files changed, 32 insertions(+), 6 deletions(-)
PATCH 1/4 documentation: Clarify wake-up/memory-barrier relationship
From: "Paul E. McKenney" <[email protected]>
This commit adds an example demonstrating that if a wake_up() doesn't actually wake something up, no memory ordering is provided.
--- Documentation/memory-barriers.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
Documentation/memory-barriers.txt +15 -0
@@ -1893,6 +1893,21 @@ between the STORE to indicate the event and the STORE to set TASK_RUNNING: <general barrier> STORE current->state LOAD event_indicated +To repeat, this write memory barrier is present if and only if something +is actually awakened. To see this, consider the following sequence of +events, where X and Y are both initially zero: + + CPU 1 CPU 2 + =============================== =============================== + X = 1; STORE event_indicated + smp_mb(); wake_up(); + Y = 1; wait_event(wq, Y == 1); + wake_up(); load from Y sees 1, no memory barrier + load from X might see 0 + +In contrast, if a wakeup does occur, CPU 2's load from X would be guaranteed +to see 1. + The available waker functions include: complete();
Signature · 1 line
1.8.1.5
PATCH 2/4 documentation: Update reference, kerneltrap.org no longer works
From: Pranith Kumar <[email protected]>
The kerneltrap.org site no longer works, so this commit updates it to a working reference, namely gmane.
--- Documentation/RCU/RTFP.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/RCU/RTFP.txt +2 -2
@@ -2451,8 +2451,8 @@ lot of {Linux} into your technology!!!" ,month="February" ,year="2010" ,note="Available: -\url{http://kerneltrap.com/mailarchive/linux-netdev/2010/2/26/6270589} -[Viewed March 20, 2011]" +\url{http://thread.gmane.org/gmane.linux.network/153338} +[Viewed June 9, 2014]" ,annotation={ Use a pair of list_head structures to support RCU-protected resizable hash tables.
Signature · 1 line
1.8.1.5
PATCH 3/4 documentation: Add acquire/release barriers to pairing rules
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
It is possible to pair acquire and release barriers with other barriers, so this commit adds them to the list in the SMP barrier pairing section.
--- Documentation/memory-barriers.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
Documentation/memory-barriers.txt +6 -4
@@ -757,10 +757,12 @@ SMP BARRIER PAIRING When dealing with CPU-CPU interactions, certain types of memory barrier should always be paired. A lack of appropriate pairing is almost certainly an error. -A write barrier should always be paired with a data dependency barrier or read -barrier, though a general barrier would also be viable. Similarly a read -barrier or a data dependency barrier should always be paired with at least an -write barrier, though, again, a general barrier is viable: +A write barrier should always be paired with a data dependency barrier, +acquire barrier, release barrier, or read barrier, though a general +barrier would also be viable. Similarly a read barrier or a data +dependency barrier should always be paired with at least a write barrier, +an acquire barrier, or a release barrier, though, again, a general +barrier is viable: CPU 1 CPU 2 =============== ===============
Signature · 1 line
1.8.1.5
Peter Zijlstra
maintainerRe: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
Documentation/memory-barriers.txt SMP BARRIER PAIRING
Quoted 13 lines · Paul E. McKenney
From: "Paul E. McKenney" <[email protected]>
It is possible to pair acquire and release barriers with other barriers, so this commit adds them to the list in the SMP barrier pairing section.
Reported-by Lai Jiangshan <[email protected]>Signed-off-by Paul E. McKenney <[email protected]>Reviewed-by Tejun Heo <[email protected]>Documentation/memory-barriers.txt +3
-0+A write barrier should always be paired with a data dependency barrier, +acquire barrier, release barrier, or read barrier, though a general +barrier would also be viable.
Similarly a read barrier or a data
Documentation/memory-barriers.txt SMP BARRIER PAIRING · line 765
Quoted 3 lines
Documentation/memory-barriers.txt +3
-0+dependency barrier should always be paired with at least a write barrier, +an acquire barrier, or a release barrier, though, again, a general +barrier is viable:
When I first read the Changelog I though you were going to add things like:
An acquire barrier should be paired with a release barrier, however .... barrier is also viable.
A release barrier should be paired with an acquire barrier,... etc.
Now the above does seem to imply such rules but it isn't explicit in them, since it only lists the requirements for read/write. Now since the entire thing is indeed symmetric the implications are fairly strong, still.
Also, it might be good to have a section on the ramifications of pairing acquire/release with other than themselves, I have the feeling there's subtle things there.
Re: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
Quoted 26 lines · Peter Zijlstra
Documentation/memory-barriers.txt SMP BARRIER PAIRING
Quoted 13 lines · Paul E. McKenney
From: "Paul E. McKenney" <[email protected]>
It is possible to pair acquire and release barriers with other barriers, so this commit adds them to the list in the SMP barrier pairing section.
Reported-by Lai Jiangshan <[email protected]>Signed-off-by Paul E. McKenney <[email protected]>Reviewed-by Tejun Heo <[email protected]>Documentation/memory-barriers.txt +3
-0+A write barrier should always be paired with a data dependency barrier, +acquire barrier, release barrier, or read barrier, though a general +barrier would also be viable.Similarly a read barrier or a data
Documentation/memory-barriers.txt SMP BARRIER PAIRING · line 765
Quoted 3 lines
Documentation/memory-barriers.txt +3
-0+dependency barrier should always be paired with at least a write barrier, +an acquire barrier, or a release barrier, though, again, a general +barrier is viable:When I first read the Changelog I though you were going to add things like:
An acquire barrier should be paired with a release barrier, however .... barrier is also viable.
Quoted 6 lines
A release barrier should be paired with an acquire barrier,... etc.
Now the above does seem to imply such rules but it isn't explicit in them, since it only lists the requirements for read/write. Now since the entire thing is indeed symmetric the implications are fairly strong, still.
Good point, how about the following?
General barriers pair with each other, though they also pair with most other types of barriers, albeit without transitivity. An acquire barrier pairs with a release barrier, but both may also pair with other barriers, including of course general barriers. A write barrier pairs with a data dependency barrier, an acquire barrier, a release barrier, a read barrier, or a general barrier. Similarly a read barrier or a data dependency barrier pairs with a write barrier, an acquire barrier, a release barrier, or a general barrier:
Quoted 3 lines
Also, it might be good to have a section on the ramifications of pairing acquire/release with other than themselves, I have the feeling there's subtle things there.
It can get quite subtle. For the time being, I am dodging this subtlety by saying that only general barriers provide transitivity (see the "TRANSITIVITY" section).
To give but one example of the subtlety, given X, Y, and Z all initially zero where it matters:
X=2; Y=2; Z=2; smp_wmb(); smp_wmb(); smp_wmb(); Y=1; Z=1; X=1; BUG_ON(X==2 && Y==2 && Z==2); /* Never triggers. */
But:
X=2; Y=2; Z=2; smp_wmb(); smp_wmb(); smp_mb(); Y=1; Z=1; r1=X; BUG_ON(r1==0 && Y==2 && Z==2); /* Can trigger!!! */
Maybe some day we should capture this subtlety in memory-barriers.txt, but we will first need a new generation of small children who are not scared by the current document. ;-)
Thanx, Paul
Peter Zijlstra
maintainerRe: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
Quoted 8 lines · Paul E. McKenney
Good point, how about the following?
General barriers pair with each other, though they also pair with most other types of barriers, albeit without transitivity.
An acquire barrier pairs with a release barrier, but both may also pair with other barriers, including of course general barriers.
Quoted 6 lines
A write barrier pairs with a data dependency barrier, an acquire barrier, a release barrier, a read barrier, or a general barrier.
Similarly a read barrier or a data dependency barrier pairs with a write barrier, an acquire barrier, a release barrier, or a general barrier:
It might be clearer with the added whitespace, or as an explicit list I suppose, but yes.
Quoted 7 lines
Quoted 3 lines
Also, it might be good to have a section on the ramifications of pairing acquire/release with other than themselves, I have the feeling there's subtle things there.
It can get quite subtle. For the time being, I am dodging this subtlety by saying that only general barriers provide transitivity (see the "TRANSITIVITY" section).
Ah, I was more thinking of the fact that ACQUIRE/RELEASE are semi-permeable while READ/WRITE are memop dependent.
So any combination will be a semi-permeable memop dependent thing, which is the most narrow barrier possible.
So if we thing of ACQUIRE/RELEASE as being 'half' a full barrier, separated in direction, and READ/WRITE as being 'half' a full barrier separated on type, then the combination is a 'quarter' barrier.
Not arguing they're not useful, just saying we need to be extra careful.
Quoted 3 lines
Maybe some day we should capture this subtlety in memory-barriers.txt, but we will first need a new generation of small children who are not scared by the current document. ;-)
Lolz :-)
Re: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
Quoted 13 lines · Peter Zijlstra
Quoted 10 lines · Paul E. McKenney
Good point, how about the following?
General barriers pair with each other, though they also pair with most other types of barriers, albeit without transitivity.
An acquire barrier pairs with a release barrier, but both may also pair with other barriers, including of course general barriers.
A write barrier pairs with a data dependency barrier, an acquire barrier, a release barrier, a read barrier, or a general barrier.
Quoted 6 lines
Quoted 3 lines
Similarly a read barrier or a data dependency barrier pairs with a write barrier, an acquire barrier, a release barrier, or a general barrier:
It might be clearer with the added whitespace, or as an explicit list I suppose, but yes.
If I get ambitious, I might try making a table out of it, but I am not yet sure how I would set that up. Something about having to say a lot in each cell, but with only a small amount of room in which to say it.
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
Also, it might be good to have a section on the ramifications of pairing acquire/release with other than themselves, I have the feeling there's subtle things there.
It can get quite subtle. For the time being, I am dodging this subtlety by saying that only general barriers provide transitivity (see the "TRANSITIVITY" section).
Ah, I was more thinking of the fact that ACQUIRE/RELEASE are semi-permeable while READ/WRITE are memop dependent.
Quoted 8 lines
So any combination will be a semi-permeable memop dependent thing, which is the most narrow barrier possible.
So if we thing of ACQUIRE/RELEASE as being 'half' a full barrier, separated in direction, and READ/WRITE as being 'half' a full barrier separated on type, then the combination is a 'quarter' barrier.
Not arguing they're not useful, just saying we need to be extra careful.
I do agree completely about the need for extra care!
For whatever it is worth, the permeability and read-write properties are isolated to each barrier in the pair. For example, with "a" and "b" both initially zero:
CPU 1 CPU 2 ----- ----- ACCESS_ONCE(a) = 1; r1 = b; smp_store_release(&b, 1); smp_rmb(); ACCESS_ONCE(c) = 1; r2 = a; ACCESS_ONCE(c) = 2;
The outcome r1==1&&r2==0 is prohibited, but the ordering of the stores to "c" are not ordered: CPU 1's smp_store_release() does not affect later accesses, and CPU 2's smp_rmb() does not order stores.
Not sure that it is worth adding this sort of example, though.
Thanx, Paul
Quoted 5 lines
Quoted 3 lines
Maybe some day we should capture this subtlety in memory-barriers.txt, but we will first need a new generation of small children who are not scared by the current document. ;-)
Lolz :-)
Peter Zijlstra
maintainerRe: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
Quoted 18 lines · Paul E. McKenney
Quoted 17 lines · Peter Zijlstra
Quoted 14 lines · Paul E. McKenney
Good point, how about the following?
General barriers pair with each other, though they also pair with most other types of barriers, albeit without transitivity.
An acquire barrier pairs with a release barrier, but both may also pair with other barriers, including of course general barriers.
A write barrier pairs with a data dependency barrier, an acquire barrier, a release barrier, a read barrier, or a general barrier.
Similarly a read barrier or a data dependency barrier pairs with a write barrier, an acquire barrier, a release barrier, or a general barrier:
Quoted 6 lines
Quoted 2 lines
It might be clearer with the added whitespace, or as an explicit list I suppose, but yes.
If I get ambitious, I might try making a table out of it, but I am not yet sure how I would set that up. Something about having to say a lot in each cell, but with only a small amount of room in which to say it.
| mb | wmb | rmb | rbd | acq | rel |
-----+-----+-----+-----+-----+-----+-----+
mb | X | X | X | X | X | X |
-----+-----+-----+-----+-----+-----+-----+
wmb | X | | X | X | | |
-----+-----+-----+-----+-----+-----+-----+
rmb | X | X | | | | |
-----+-----+-----+-----+-----+-----+-----+
rbd | X | X | | | | |
-----+-----+-----+-----+-----+-----+-----+
acq | X | | | | | X |
-----+-----+-----+-----+-----+-----+-----+
rel | X | | | | X | |
-----+-----+-----+-----+-----+-----+-----+
(where rbd is read_barrier_depends).
Which is not entirely filled out, in particular I didn't do the creative acq/rel bits.
Quoted 25 lines
Quoted 11 lines
Ah, I was more thinking of the fact that ACQUIRE/RELEASE are semi-permeable while READ/WRITE are memop dependent.
So any combination will be a semi-permeable memop dependent thing, which is the most narrow barrier possible.
So if we thing of ACQUIRE/RELEASE as being 'half' a full barrier, separated in direction, and READ/WRITE as being 'half' a full barrier separated on type, then the combination is a 'quarter' barrier.
Not arguing they're not useful, just saying we need to be extra careful.
I do agree completely about the need for extra care!
For whatever it is worth, the permeability and read-write properties are isolated to each barrier in the pair. For example, with "a" and "b" both initially zero:
CPU 1 CPU 2 ----- ----- ACCESS_ONCE(a) = 1; r1 = b; smp_store_release(&b, 1); smp_rmb(); ACCESS_ONCE(c) = 1; r2 = a; ACCESS_ONCE(c) = 2;
Quoted 5 lines
The outcome r1==1&&r2==0 is prohibited, but the ordering of the stores to "c" are not ordered: CPU 1's
smp_store_release()does not affect later accesses, and CPU 2'ssmp_rmb()does not order stores.Not sure that it is worth adding this sort of example, though.
Yeah, not sure either. Maybe just a big fat caution if you pair acq/rel with anything other than its opposite or a general barrier.
Maybe use small 'x' for acq/rel + rmb/wmb and put a caution in the 'legend' for 'x'.
Re: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
Quoted 42 lines · Peter Zijlstra
Quoted 18 lines · Paul E. McKenney
Quoted 17 lines · Peter Zijlstra
Quoted 14 lines · Paul E. McKenney
Good point, how about the following?
General barriers pair with each other, though they also pair with most other types of barriers, albeit without transitivity.
An acquire barrier pairs with a release barrier, but both may also pair with other barriers, including of course general barriers.
A write barrier pairs with a data dependency barrier, an acquire barrier, a release barrier, a read barrier, or a general barrier.
Similarly a read barrier or a data dependency barrier pairs with a write barrier, an acquire barrier, a release barrier, or a general barrier:
Quoted 6 lines
Quoted 2 lines
It might be clearer with the added whitespace, or as an explicit list I suppose, but yes.
If I get ambitious, I might try making a table out of it, but I am not yet sure how I would set that up. Something about having to say a lot in each cell, but with only a small amount of room in which to say it.
| mb | wmb | rmb | rbd | acq | rel |
-----+-----+-----+-----+-----+-----+-----+
mb | X | X | X | X | X | X |
-----+-----+-----+-----+-----+-----+-----+
wmb | X | | X | X | | |
-----+-----+-----+-----+-----+-----+-----+
rmb | X | X | | | | |
-----+-----+-----+-----+-----+-----+-----+
rbd | X | X | | | | |
-----+-----+-----+-----+-----+-----+-----+
acq | X | | | | | X |
-----+-----+-----+-----+-----+-----+-----+
rel | X | | | | X | |
-----+-----+-----+-----+-----+-----+-----+
Quoted 4 lines
(where rbd is
read_barrier_depends).Which is not entirely filled out, in particular I didn't do the creative acq/rel bits.
Also needs to reflect that wmb really can pair with wmb. See for example Scenario 15 of https://lwn.net/Articles/573436/. Then again, your point might be that Scenario 15 is not all that useful, which is true in my experience -- though a good way to cause someone to find a use is to leave it out of such a table...
Quoted 29 lines
Quoted 29 lines
Quoted 11 lines
Ah, I was more thinking of the fact that ACQUIRE/RELEASE are semi-permeable while READ/WRITE are memop dependent.
So any combination will be a semi-permeable memop dependent thing, which is the most narrow barrier possible.
So if we thing of ACQUIRE/RELEASE as being 'half' a full barrier, separated in direction, and READ/WRITE as being 'half' a full barrier separated on type, then the combination is a 'quarter' barrier.
Not arguing they're not useful, just saying we need to be extra careful.
I do agree completely about the need for extra care!
For whatever it is worth, the permeability and read-write properties are isolated to each barrier in the pair. For example, with "a" and "b" both initially zero:
CPU 1 CPU 2 ----- ----- ACCESS_ONCE(a) = 1; r1 = b; smp_store_release(&b, 1); smp_rmb(); ACCESS_ONCE(c) = 1; r2 = a; ACCESS_ONCE(c) = 2;The outcome r1==1&&r2==0 is prohibited, but the ordering of the stores to "c" are not ordered: CPU 1's
smp_store_release()does not affect later accesses, and CPU 2'ssmp_rmb()does not order stores.
Quoted 7 lines
Quoted 1 line
Not sure that it is worth adding this sort of example, though.
Yeah, not sure either. Maybe just a big fat caution if you pair acq/rel with anything other than its opposite or a general barrier.
Maybe use small 'x' for acq/rel + rmb/wmb and put a caution in the 'legend' for 'x'.
When I expand things out, I end up wanting each cell to hold a scenario from the tables in https://lwn.net/Articles/573436/ and
https://lwn.net/Articles/573497/, probably along with some cautions on what it does not do as well. :-(
Thanx, Paul
Mathieu Desnoyers
reviewerRe: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
----- Original Message -----
Quoted 99 lines
From: "Paul E. McKenney" <[email protected]>
To: "Peter Zijlstra" <[email protected]>
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], "mathieu desnoyers" <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Sent: Wednesday, July 16, 2014 9:18:55 AM
Subject: Re: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rulesQuoted 43 lines · Peter Zijlstra
Quoted 18 lines · Paul E. McKenney
Quoted 17 lines · Peter Zijlstra
Quoted 14 lines · Paul E. McKenney
Good point, how about the following?
General barriers pair with each other, though they also pair with most other types of barriers, albeit without transitivity.
An acquire barrier pairs with a release barrier, but both may also pair with other barriers, including of course general barriers.
A write barrier pairs with a data dependency barrier, an acquire barrier, a release barrier, a read barrier, or a general barrier.
Similarly a read barrier or a data dependency barrier pairs with a write barrier, an acquire barrier, a release barrier, or a general barrier:
Quoted 7 lines
Quoted 3 lines
It might be clearer with the added whitespace, or as an explicit list I
suppose, but yes.If I get ambitious, I might try making a table out of it, but I am not yet sure how I would set that up. Something about having to say a lot in each cell, but with only a small amount of room in which to say it.
| mb | wmb | rmb | rbd | acq | rel |
-----+-----+-----+-----+-----+-----+-----+
mb | X | X | X | X | X | X |
-----+-----+-----+-----+-----+-----+-----+
wmb | X | | X | X | | |
-----+-----+-----+-----+-----+-----+-----+
rmb | X | X | | | | |
-----+-----+-----+-----+-----+-----+-----+
rbd | X | X | | | | |
-----+-----+-----+-----+-----+-----+-----+
acq | X | | | | | X |
-----+-----+-----+-----+-----+-----+-----+
rel | X | | | | X | |
-----+-----+-----+-----+-----+-----+-----+Quoted 4 lines
(where rbd is
read_barrier_depends).Which is not entirely filled out, in particular I didn't do the creative acq/rel bits.
Also needs to reflect that wmb really can pair with wmb. See for example Scenario 15 of https://lwn.net/Articles/573436/. Then again, your point might be that Scenario 15 is not all that useful, which is true in my experience -- though a good way to cause someone to find a use is to leave it out of such a table...
Quoted 35 lines
Quoted 26 lines
Quoted 6 lines
Ah, I was more thinking of the fact that ACQUIRE/RELEASE are semi-permeable while READ/WRITE are memop dependent.
So any combination will be a semi-permeable memop dependent thing, which is the most narrow barrier possible.
Quoted 6 lines
So if we thing of ACQUIRE/RELEASE as being 'half' a full barrier, separated in direction, and READ/WRITE as being 'half' a full barrier separated on type, then the combination is a 'quarter' barrier.
Not arguing they're not useful, just saying we need to be extra careful.
I do agree completely about the need for extra care!
For whatever it is worth, the permeability and read-write properties are isolated to each barrier in the pair. For example, with "a" and "b" both initially zero:
CPU 1 CPU 2 ----- ----- ACCESS_ONCE(a) = 1; r1 = b; smp_store_release(&b, 1); smp_rmb(); ACCESS_ONCE(c) = 1; r2 = a; ACCESS_ONCE(c) = 2;Quoted 5 lines
The outcome r1==1&&r2==0 is prohibited, but the ordering of the stores to "c" are not ordered: CPU 1's
smp_store_release()does not affect later accesses, and CPU 2'ssmp_rmb()does not order stores.Not sure that it is worth adding this sort of example, though.
Yeah, not sure either. Maybe just a big fat caution if you pair acq/rel with anything other than its opposite or a general barrier.
Quoted 7 lines
Quoted 2 lines
Maybe use small 'x' for acq/rel + rmb/wmb and put a caution in the 'legend' for 'x'.
When I expand things out, I end up wanting each cell to hold a scenario from the tables in https://lwn.net/Articles/573436/ and
https://lwn.net/Articles/573497/, probably along with some cautions on what it does not do as well. :-(
The table you just proposed seems to fit well as a "memory barrier cheat sheet" to remind the usual pairing that can be explained in a single sentence each.
Then you could point out that this table is indeed incomplete, and point to a separate URL for detailed explanation of the more elaborate, seldom used pairing.
Thoughts ?
Thanks,
Mathieu
Quoted 4 lines
Thanx, Paul
Signature · 3 lines
Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
PATCH 4/4 documentation: Add pointer to percpu-ref for RCU and refcount
In reply to Paul E. McKenneyFrom: "Paul E. McKenney" <[email protected]>
--- Documentation/RCU/rcuref.txt | 9 +++++++++ 1 file changed, 9 insertions(+)
Documentation/RCU/rcuref.txt +9 -0
@@ -1,5 +1,14 @@ Reference-count design for elements of lists/arrays protected by RCU. + +Please note that the percpu-ref feature is likely your first +stop if you need to combine reference counts and RCU. Please see +include/linux/percpu-refcount.h for more information. However, in +those unusual cases where percpu-ref would consume too much memory, +please read on. + +------------------------------------------------------------------------ + Reference counting on elements of lists which are protected by traditional reader/writer spinlocks or semaphores are straightforward:
Signature · 1 line
1.8.1.5
Re: [PATCH tip/core/rcu 1/4] documentation: Clarify wake-up/memory-barrier relationship
In reply to Paul E. McKenneyQuoted 7 lines · Paul E. McKenney
From: "Paul E. McKenney" <[email protected]>
This commit adds an example demonstrating that if a
wake_up()doesn't actually wake something up, no memory ordering is provided.Reported-by Peter Zijlstra <[email protected]>Signed-off-by Paul E. McKenney <[email protected]>
Thanks,
Quoted 4 lines · Paul E. McKenney
Hello!
This series provides a few documentation updates:
Quoted 8 lines
1. Clarify that if there is nothing awakened, then there is no
memory barrier.2. Fix broken RTFP URL, courtesy of Pranith Kumar.
3. Add acquire/release barrier to memory-barrier pairing rules.
4. Add pointer to percpu-ref in rcuref.txt documentation.
For all four:
Lai Jiangshan
Reviewed-byQuoted 10 lines · Josh Triplett
Quoted 9 lines · Paul E. McKenney
Hello!
This series provides a few documentation updates:
1. Clarify that if there is nothing awakened, then there is no
memory barrier.2. Fix broken RTFP URL, courtesy of Pranith Kumar.
Quoted 9 lines
Quoted 3 lines
3. Add acquire/release barrier to memory-barrier pairing rules.
4. Add pointer to percpu-ref in rcuref.txt documentation.
For all four:
Reviewed-by Josh Triplett <[email protected]>.
For patch 1 ("documentation: Clarify wake-up/memory-barrier relationship") and patch 4 ("documentation: Add pointer to percpu-ref for RCU and refcount")