On Fri, Mar 1, 2024 at 4:50 AM Yan Zhai <[email protected]> wrote: > > On Thu, Feb 29, 2024 at 9:47 PM Yan Zhai <[email protected]> wrote: > > > > We noticed task RCUs being blocked when threaded NAPIs are very busy at > > workloads: detaching any BPF tracing programs, i.e. removing a ftrace > > trampoline, will simply block for very long in rcu_tasks_wait_gp. This > > ranges from hundreds of seconds to even an hour, severely harming any ... > > > > Fixes: 29863d41bb6e ("net: implement threaded-able napi poll loop support") > > Suggested-by: Paul E. McKenney <[email protected]> > > Reviewed-by: Joel Fernandes (Google) <[email protected]> > > Signed-off-by: Yan Zhai <[email protected]> > > --- > > v1->v2: moved rcu_softirq_qs out from bh critical section, and only > > raise it after a second of repolling. Added some brief perf test result. > > > Link to v1: https://lore.kernel.org/netdev/[email protected]/T/#u > And I apparently forgot to rename the subject since it's not raising > after every poll (let me know if it is prefered to send a V3 to fix > it) >
I could not see the reason for 1sec (HZ) delays. Would calling rcu_softirq_qs() every ~10ms instead be a serious issue ? In anycase, if this all about rcu_tasks, I would prefer using a macro defined in kernel/rcu/tasks.h instead of having a hidden constant in a networking core function. Thanks.
