Message ID | 20250116200239.3782374-2-paulmck@kernel.org (mailing list archive) |
---|---|
State | Accepted |
Commit | 21904a69ff550ac58a8e5e9c1b497e38fa27eac6 |
Headers | show |
Series | Documentation upates | expand |
On Thu, Jan 16, 2025 at 12:02:34PM -0800, Paul E. McKenney wrote: > +The special cases where it makes sense do obtain a per-CPU pointer in s/do/to/ > +preemptible code are addressed by raw_cpu_ptr(), but please note that such s/please note that // > +use cases need to handle cases where two different CPUs are accessing > +the same per cpu variable, which might well be that of a third CPU. > +These use cases are typically performance optimizations. For example, > +SRCU implements a pair of counters as a pair of per-CPU variables, > +and rcu_read_lock_nmisafe() uses raw_cpu_ptr() to get a pointer to some > +CPU's counter, and uses atomic_inc_long() to handle migration between > +the raw_cpu_ptr() and the atomic_inc_long().
On Thu, Jan 16, 2025 at 09:02:16PM +0000, Matthew Wilcox wrote: > On Thu, Jan 16, 2025 at 12:02:34PM -0800, Paul E. McKenney wrote: > > +The special cases where it makes sense do obtain a per-CPU pointer in > > s/do/to/ > > > +preemptible code are addressed by raw_cpu_ptr(), but please note that such > > s/please note that // Good eyes, thank you! I am a bit sorry to see the "please note that" go, but I suppose fewer words is a good thing. I will fix these on my next rebase and repost. Thanx, Paul > > +use cases need to handle cases where two different CPUs are accessing > > +the same per cpu variable, which might well be that of a third CPU. > > +These use cases are typically performance optimizations. For example, > > +SRCU implements a pair of counters as a pair of per-CPU variables, > > +and rcu_read_lock_nmisafe() uses raw_cpu_ptr() to get a pointer to some > > +CPU's counter, and uses atomic_inc_long() to handle migration between > > +the raw_cpu_ptr() and the atomic_inc_long().
diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst index 91acbcf30e9bd..11e3e48731553 100644 --- a/Documentation/core-api/this_cpu_ops.rst +++ b/Documentation/core-api/this_cpu_ops.rst @@ -138,12 +138,22 @@ get_cpu/put_cpu sequence requires. No processor number is available. Instead, the offset of the local per cpu area is simply added to the per cpu offset. -Note that this operation is usually used in a code segment when -preemption has been disabled. The pointer is then used to -access local per cpu data in a critical section. When preemption -is re-enabled this pointer is usually no longer useful since it may -no longer point to per cpu data of the current processor. - +Note that this operation can only be used in code segments where +smp_processor_id() may be used, for example, where preemption has been +disabled. The pointer is then used to access local per cpu data in a +critical section. When preemption is re-enabled this pointer is usually +no longer useful since it may no longer point to per cpu data of the +current processor. + +The special cases where it makes sense do obtain a per-CPU pointer in +preemptible code are addressed by raw_cpu_ptr(), but please note that such +use cases need to handle cases where two different CPUs are accessing +the same per cpu variable, which might well be that of a third CPU. +These use cases are typically performance optimizations. For example, +SRCU implements a pair of counters as a pair of per-CPU variables, +and rcu_read_lock_nmisafe() uses raw_cpu_ptr() to get a pointer to some +CPU's counter, and uses atomic_inc_long() to handle migration between +the raw_cpu_ptr() and the atomic_inc_long(). Per cpu variables and offsets -----------------------------
Most of the this_cpu_*() operations may be used in preemptible code, but not this_cpu_ptr(), and for good reasons. Therefore, better explain the reasons and call out raw_cpu_ptr() as an alternative in certain very special cases. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: <linux-doc@vger.kernel.org> --- Documentation/core-api/this_cpu_ops.rst | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)