Re: [PATCH] net: raise RCU qs after each threaded NAPI poll
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2024-02-28 22:31:05
Also in:
bpf, lkml, rcu
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2024-02-28 22:31:05
Also in:
bpf, lkml, rcu
On Wed, 28 Feb 2024 14:19:11 -0800 "Paul E. McKenney" [off-list ref] wrote:
quoted
quoted
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. [ Added Alexei ] -- Steve