Le Wed, Jan 14, 2026 at 12:31:53PM -0500, Joel Fernandes a écrit : > During callback overload, the NOCB code attempts an opportunistic > advancement via rcu_advance_cbs_nowake(). > > Analysis via tracing with 300,000 callbacks flooded shows this > optimization is likely dead code: > - 30 overload conditions triggered > - 0 advancements actually occurred > - 100% of time no advancement due to current GP not done. > > I also ran TREE05 and TREE08 for 2 hours and cannot trigger it. > > When callbacks overflow (exceed qhimark), they are waiting for a grace > period that hasn't completed yet. The optimization requires the GP to be > complete to advance callbacks, but the overload condition itself is > caused by callbacks piling up faster than GPs can complete. This creates > a logical contradiction where the advancement cannot happen. > > In *theory* this might be possible, the GP completed just in the nick of > time as we hit the overload, but this is just so rare that it can be > considered impossible when we cannot even hit it with synthetic callback > flooding even, it is a waste of cycles to even try to advance, let alone > be useful and is a maintenance burden complexity we don't need.
Rare is far from impossible with billions of android devices living out there. I can imagine the warning to just hit if the flooding callback enqueuer happen to hit the qhimark right after the GP has completed but before nocb_gp_wait() managed yet to advance the callbacks. But what would that prove then? > > I suggest deletion. However, add a WARN_ON_ONCE for a merge window or 2 > and delete it after out of extreme caution. 2 merge windows is the least of time for that warning to ever land on the billions machines. My phone still runs a v5.4 kernel :-) And the patch doesn't quite qualify for a stable backport. Anyway, consider an unpleasant case where nocb_gp_wait() is starving for example. How would just advancing the callbacks help? We still need nocb_gp_wait() to run its round to eventually wake up nocb_cb_wait() so that the done callbacks are executed. And before doing that, it needs to advance the callbacks anyway... I'm personally in favour of removing this right away instead, unless Paul has a good reason that I missed? Thanks. -- Frederic Weisbecker SUSE Labs
