Thread (32 messages) 32 messages, 6 authors, 22d ago

Re: [PATCH RFC v2 08/15] bpf, x86: Maintain Tasks RCU trampoline nesting in the BPF trampoline

flat view

From: Alexei Starovoitov <hidden>
Date: 2026-09-12 19:40:58
Also in: bpf, linux-trace-kernel, lkml, rcu, xen-devel

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
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help