On Wed, 3 Jul 2024 09:50:57 +0200 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > However, in the past, the memory-barrier and array-indexing overhead > > of SRCU has made it a no-go for lightweight probes into fastpath code. > > And these cases were what motivated RCU Tasks Trace (as opposed to RCU > > Tasks Rude). > > I'm thinking we're growing too many RCU flavours again :/ I suppose I'll > have to go read up on rcu/tasks.* and see what's what. This RCU flavor is the one to handle trampolines. If the trampoline never voluntarily schedules, then the quiescent state is a voluntary schedule. The issue with trampolines is that if something was preempted as it was jumping to a trampoline, there's no way to know when it is safe to free that trampoline, as some preempted task's next instruction is on that trampoline. Any trampoline that does not voluntary schedule can use RCU task synchronization. As it will wait till all tasks have voluntarily scheduled or have entered user space (IIRC, Paul can correct me if I'm wrong). Now, if a trampoline does schedule, it would need to incorporate some ref counting on the trampoline to handle the scheduling, but could still use RCU task synchronization up to the point of the ref count. And yes, the rude flavor was to handle the !rcu_is_watching case, and can now be removed. -- Steve
