On Wed, Feb 28, 2024 at 10:37:51AM -0600, Yan Zhai wrote:
> On Wed, Feb 28, 2024 at 9:37 AM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote:
> > Also optionally, I wonder if calling rcu_tasks_qs() directly is better
> > (for documentation if anything) since the issue is Tasks RCU specific. Also
> > code comment above the rcu_softirq_qs() call about cond_resched() not taking
> > care of Tasks RCU would be great!
> >
> Yes it's quite surprising to me that cond_resched does not help here,
In theory, it would be possible to make cond_resched() take care of
Tasks RCU. In practice, the lazy-preemption work is looking to get rid
of cond_resched(). But if for some reason cond_resched() needs to stay
around, doing that work might make sense.
> I will include that comment. Raising just the task RCU QS seems
> sufficient to the problem we encountered. But according to commit
> d28139c4e967 ("rcu: Apply RCU-bh QSes to RCU-sched and RCU-preempt
> when safe"), there might be additional threat factor in __do_softirq
> that also applies to threaded poll.
We did look into more focused alternatives for Tasks RCU a few days ago,
but they all had problems, for example, requiring that it be possible
to get exact information on the instruction pointers for interrupts on
any given CPU's stack. The key point of Tasks RCU is to work out when
an old tracing trampoline may safely be freed, so a better way of doing
that would remove the need for this sort of addition to NAPI polling.
(Adding Steve and Mark for their thoughts.)
Thanx, Paul
> Yan
>
>
> > Reviewed-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx>
> >
> > thanks,
> >
> > - Joel
> > [1]
> > @@ -381,8 +553,10 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
> > pending >>= softirq_bit;
> > }
> >
> > - if (__this_cpu_read(ksoftirqd) == current)
> > + if (!IS_ENABLED(CONFIG_PREEMPT_RT) &&
> > + __this_cpu_read(ksoftirqd) == current)
> > rcu_softirq_qs();
> > +
> > local_irq_disable();
