On Fri, Mar 1, 2024 at 4:50 AM Yan Zhai <yan@xxxxxxxxxxxxxx> wrote:
>
> On Thu, Feb 29, 2024 at 9:47 PM Yan Zhai <yan@xxxxxxxxxxxxxx> 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 <paulmck@xxxxxxxxxx>
> > Reviewed-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx>
> > Signed-off-by: Yan Zhai <yan@xxxxxxxxxxxxxx>
> > ---
> > 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/Zd4DXTyCf17lcTfq@debian.debian/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.
