Re: [PATCH -next v3 2/3] rcu/nocb: Remove dead callback overload handling

[Joel Fernandes <joelagnelf@nvidia.com>]

On Fri, Jan 23, 2026 at 01:27:46PM -0800, Paul E. McKenney wrote:
> On Fri, Jan 23, 2026 at 02:36:37PM -0500, Joel Fernandes wrote:
> > I was coming more from the point of view of improving grace period performance
> > when we do have an overload, potentially resolving the overloaded situation
> > faster than usual. We would dynamically trigger polling based on such
> > circumstances.
> >
> > That said, I confess I don't have extensive experience with polling mode beyond
> > testing. I believe we should add more rcutorture test cases for this. I'm
> > considering adding a new config that enables polling for NOCB - this testing is
> > what revealed the potential for grace period performance improvement with NOCB
> > to me.
>
> The main purpose of polling was to make call_rcu() avoid at least some
> of its slowpaths.  If we are getting some other benefit out of it, is
> polling the best way to achieve that benefit?

I only started looking into this, but there is the rcu_state.cbovld flag
which already does similar "extra work at the expense of more CPU" when
callback overload is detected. Specifically, when cbovld is set (triggered
when any CPU exceeds qovld_calc callbacks, default 20,000), the following
aggressive measures kick in:

1. FQS intervals are shortened making force quiescent
   state scans happen more frequently.

2. Heavy quiescent state requests are triggered earlier.

3. Priority boosting kicks in immediately rather than waiting.

These are already along the same lines as what I was suggesting for polling:
do extra work at the expense of more CPU cycles to reduce the overload
situation faster. So perhaps the question is whether dynamically enabling
poll mode during cbovld would provide additional benefit on top of these.

As you said, the idea was to avoid the call rcu slow paths. But perhaps it
can also assist cbovld too?

I will study this more :)

Thanks,
--
Joel Fernandes