[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z4lz2CC7SLgSp90y@casper.infradead.org>
Date: Thu, 16 Jan 2025 21:02:16 +0000
From: Matthew Wilcox <willy@...radead.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
rostedt@...dmis.org, Jonathan Corbet <corbet@....net>,
Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>,
Boqun Feng <boqun.feng@...il.com>, linux-doc@...r.kernel.org
Subject: Re: [PATCH rcu 2/7] docs: Improve discussion of this_cpu_ptr(), add
raw_cpu_ptr()
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().
Powered by blists - more mailing lists