diff options
| author | Puranjay Mohan <puranjay@kernel.org> | 2026-06-24 06:23:51 -0700 |
|---|---|---|
| committer | Paul E. McKenney <paulmck@kernel.org> | 2026-07-24 16:56:48 -0700 |
| commit | fde2b18817e4f32b92c1e9881356fbc314983a7a (patch) | |
| tree | fd47ed30641297d219c69d04d27ab92e94052740 /tools/lib/python | |
| parent | 318606106c610714608da56cb9a2699040a26b53 (diff) | |
| download | linux-fde2b18817e4f32b92c1e9881356fbc314983a7a.tar.gz linux-fde2b18817e4f32b92c1e9881356fbc314983a7a.zip | |
rcu: Detect expedited grace period completion in rcu_pending()
rcu_pending() decides whether rcu_core() should run on the current CPU's
timer tick. It does not account for expedited grace periods: after an
expedited GP completes, a non-offloaded CPU's callbacks remain in
RCU_WAIT_TAIL (not yet advanced to RCU_DONE_TAIL) and rcu_core() is
never invoked to advance them.
Detect that case via rcu_segcblist_nextgp() combined with a new
memory-ordering-free poll variant,
poll_state_synchronize_rcu_full_unordered(). This keeps rcu_pending()
cheap: it runs on every tick that has pending callbacks, so it must
not pay for the two memory barriers in
poll_state_synchronize_rcu_full(). The check is only a hint to run
rcu_core(); the ordered re-check and the actual callback advancement
happen there.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions
