[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260119145938.GJ831050@noisy.programming.kicks-ass.net>
Date: Mon, 19 Jan 2026 15:59:38 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: Shrikanth Hegde <sshegde@...ux.ibm.com>,
Vishal Chourasia <vishalc@...ux.ibm.com>, boqun.feng@...il.com,
frederic@...nel.org, josh@...htriplett.org,
linux-kernel@...r.kernel.org, neeraj.upadhyay@...nel.org,
paulmck@...nel.org, rcu@...r.kernel.org, rostedt@...dmis.org,
srikar@...ux.ibm.com, tglx@...utronix.de, urezki@...il.com,
samir@...ux.ibm.com
Subject: Re: [PATCH] cpuhp: Expedite synchronize_rcu during SMT switch
On Mon, Jan 19, 2026 at 09:45:48AM -0500, Joel Fernandes wrote:
> On Sun, Jan 19, 2026 at 03:11:18PM +0100, Peter Zijlstra wrote:
> > By holding an extra rcu_sync reference, the percpu rwsem is kept into
> > the the slow path, avoiding the rcu-sync on down_write(), which was very
> > prevalent per this:
> >
> > https://lkml.kernel.org/r/aWU9HRcs4ghazIRg@linux.ibm.com
>
> Makes sense, though I wonder if we should have a separate percpu-rwsem API
> for this rather than directly accessing the lock-internal rcu_sync state?
> Other future percpu_rw_semaphore users may benefit as well.
Yeah, perhaps. There is one other user, the above makes two.
kernel/cgroup/cgroup.c: rcu_sync_enter(&cgroup_threadgroup_rwsem.rss);
Powered by blists - more mailing lists