On Wed, Feb 28, 2024 at 05:33:07PM -0500, Steven Rostedt wrote: > On Wed, 28 Feb 2024 14:19:11 -0800 > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > > > > > > > Well, to your initial point, cond_resched() does eventually invoke > > > > preempt_schedule_common(), so you are quite correct that as far as > > > > Tasks RCU is concerned, cond_resched() is not a quiescent state. > > > > > > Thanks for confirming. :-) > > > > However, given that the current Tasks RCU use cases wait for trampolines > > to be evacuated, Tasks RCU could make the choice that cond_resched() > > be a quiescent state, for example, by adjusting rcu_all_qs() and > > .rcu_urgent_qs accordingly. > > > > But this seems less pressing given the chance that cond_resched() might > > go away in favor of lazy preemption. > > Although cond_resched() is technically a "preemption point" and not truly a > voluntary schedule, I would be happy to state that it's not allowed to be > called from trampolines, or their callbacks. Now the question is, does BPF > programs ever call cond_resched()? I don't think they do. Nor do I, but I too must defer to Alexei. ;-) > [ Added Alexei ] The other issue with making cond_resched() be a Tasks RCU quiescent state is that the CONFIG_PREEMPTION=y version of cond_resched() would need to stop being a complete no-op. Which actually might be OK. Thanx, Paul
