On Sat Sep 12, 2026 at 11:03 AM PDT, Paul E. McKenney wrote: > > In the old kernels, yes, we have current->trc_reader_nesting++. > In the newer kernels, Tasks Trace RCU is instead implemented in terms > of SRCU-fast, which instead increments per-CPU counters. Which among > other thins is a bit faster and does not need to hook into the scheduler.
old kernels? I'm confused. rcu_read_lock_trace() in bpf-next is doing t->trc_reader_nesting++ and then calls __srcu_read_lock_fast(). Are you talking about some RCU branch that you target for next merge window? > > So we have several ways forward: > > 1. Revert the implementation of RCU Tasks Trace in terms of > SRCU-fast, and use the existing current->trc_reader_nesting++, > as you suggest. > > 2. Deprecate RCU Tasks Trace entirely in favor of RCU Tasks > augmented by rcu_tasks_trampoline_enter() and friends, as > I was suggesting. > > 3. Implement rcu_tasks_trampoline_enter() in terms of SRCU-fast, > keeping the speedup, and put a synchronize_srcu() in the > RCU Tasks grace-period mechanism. This again deprecates > RCU Tasks Trace entirely in favor of the augmented RCU Tasks. > > 4. It is always good to explicitly state the apparent status quo, > which involves redundant trampoline entry/exit overhead. > > 5. As always, your additional ideas here! > > Thanx, Paul
