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
