On Fri, Jan 23, 2026 at 02:36:37PM -0500, Joel Fernandes wrote:
> On 1/23/2026 11:49 AM, Paul E. McKenney wrote:
> > We could have one CPU flooding and the rest idle, and many other
> > combinations. And, if I recall correctly, polling can burn extra CPU
> > and cause extra wakeups even when the system is fully idle. Or has
> > that changed?
>
> In my experience working on lazy RCU, if you have such a kind of overload on
> any CPU, then you're usually not saving any power anyway. The system has to
> be really quiet and idle with a low stream of callbacks for you to save
> power. Further, when the callback length increases too much, we don't turn
> on lazy RCU anyway because the idea is that we are overloaded and the
> system is busy - so we already have such assumptions baked in. I think a
> similar argument could apply here for dynamically enabling polling mode only
> when overloaded.
The concern is detecting overload quickly. Any unnecessary gaps in
invoking RCU callbacks cannot be made up. That time is gone.
And the polling does sleeps...
> 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?
Thanx, Paul
