Re: [PATCH] cpuhp: Expedite synchronize_rcu during CPU hotplug operations

From: Shrikanth Hegde

Date: Mon Jan 12 2026 - 23:55:04 EST

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?

Whats the cost of doing this?

(Me not knowing much about rcu internals)