[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZiY-xItV0IMrGDQH@localhost.localdomain>
Date: Mon, 22 Apr 2024 12:41:08 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Lai Jiangshan <jiangshanlai@...il.com>
Cc: linux-kernel@...r.kernel.org, rcu@...r.kernel.org, x86@...nel.org,
Lai Jiangshan <jiangshan.ljs@...group.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Neeraj Upadhyay <quic_neeraju@...cinc.com>,
Joel Fernandes <joel@...lfernandes.org>,
Josh Triplett <josh@...htriplett.org>,
Boqun Feng <boqun.feng@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Zqiang <qiang.zhang1211@...il.com>
Subject: Re: [PATCH 08/10] rcu: Implement PCPU_RCU_PREEMPT_COUNT framework
Le Thu, Mar 28, 2024 at 03:53:16PM +0800, Lai Jiangshan a écrit :
> From: Lai Jiangshan <jiangshan.ljs@...group.com>
>
> When the arch code provides HAVE_PCPU_RCU_PREEMPT_COUNT and the
> corresponding functions, rcu_preempt core uses the functions to
> implement rcu_read_[un]lock, rcu_preempt_depth(), special bits,
> switching and so on.
The changelogs don't explain the reason for all of that. I'm guessing
from the cover letter that the purpose is to save some instructions on
calls to rcu_read_unlock() due to inline calls and per CPU optimized
instructions but it's hard to guess from the actual individual patches,
which are meants to be the actual git records.
Thanks.
Powered by blists - more mailing lists