On Wed, Jul 03, 2024 at 05:57:54PM -0400, Steven Rostedt wrote: > 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). Agreed! > 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. Or, if the schedule is due at most to a page fault, it can use RCU Tasks Trace. > And yes, the rude flavor was to handle the !rcu_is_watching case, and > can now be removed.
