linux-kernel - Re: [PATCH] cpuhp: Expedite synchronize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <37372899-9CA4-455D-83EB-79A07294D34A@nvidia.com>
Date: Tue, 13 Jan 2026 08:57:20 +0000
From: Joel Fernandes <joelagnelf@...dia.com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
CC: Uladzislau Rezki <urezki@...il.com>, "paulmck@...nel.org"
	<paulmck@...nel.org>, Vishal Chourasia <vishalc@...ux.ibm.com>,
	"rcu@...r.kernel.org" <rcu@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "frederic@...nel.org" <frederic@...nel.org>,
	"neeraj.upadhyay@...nel.org" <neeraj.upadhyay@...nel.org>,
	"josh@...htriplett.org" <josh@...htriplett.org>, "boqun.feng@...il.com"
	<boqun.feng@...il.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "peterz@...radead.org"
	<peterz@...radead.org>, "srikar@...ux.ibm.com" <srikar@...ux.ibm.com>
Subject: Re: [PATCH] cpuhp: Expedite synchronize_rcu during CPU hotplug
 operations



> On Jan 12, 2026, at 11:55 PM, Shrikanth Hegde <sshegde@...ux.ibm.com> wrote:
> 
> Hi.
> 
> On 1/13/26 8:16 AM, Joel Fernandes wrote:
> 
> 
>>>>>> Another way to make it in-kernel would be to make the RCU normal wake
>>>>>> from GP optimization enabled for > 16 CPUs by default.>>
>>>>>> I was considering this, but I did not bring it up because I did not
>>>>>> know that there are large systems that might benefit from it until now.>
>>>>> This would require increasing the scalability of this optimization,
>>>>> right?  Or am I thinking of the wrong optimization?  ;-)
>>>>> 
>>>> Yes I think you are considering the correct one, the concern you have is
>>>> regarding large number of wake ups initiated from the GP thread, correct?
>>>> 
>>>> I was suggesting on the thread, a more dynamic approach where using
>>>> synchronize_rcu_normal() until it gets overloaded with requests. One approach
>>>> might be to measure the length of the rcu_state.srs_next to detect an overload
>>>> condition, similar to qhimark? Or perhaps qhimark itself can be used. And under
>>>> lightly loaded conditions, default to synchronize_rcu_normal() without checking
>>>> for the 16 CPU count.
>>>> 
>>>> Thoughts?
>>> 
>>> Or maintain multiple lists.  Systems with 1000+ CPUs can be a bit
>>> unforgiving of pretty much any form of contention.
>> Makes sense. We could also just have a single list but a much smaller threshold for switching synchronize_rcu_normal off.
>> That would address the conveyor belt pattern Vishal expressed.
>> thanks,
>>  - Joel
> 
> Wouldn't that make most of the sync_rcu calls on large system
> with synchronize_rcu_normal off?

It would and that is expected.

> 
> Whats the cost of doing this?

There is no cost, that is the point right. The scalability issue Paul is referring to is the
large number of wake ups. You wont have that if the number of synchronous callers is small.

 - Joel



> 
> (Me not knowing much about rcu internals)