On Wed, Oct 06, 2021 at 04:12:12PM +0100, Valentin Schneider wrote:
> On 04/10/21 15:47, Frederic Weisbecker wrote:
> > On Fri, Oct 01, 2021 at 06:51:32PM +0100, Valentin Schneider wrote:
> >> On 30/09/21 00:10, Frederic Weisbecker wrote:
> >> > Time limit only makes sense when callbacks are serviced in softirq mode
> >> > because:
> >> >
> >> > _ In case we need to get back to the scheduler,
> >> > cond_resched_tasks_rcu_qs() is called after each callback.
> >> >
> >> > _ In case some other softirq vector needs the CPU, the call to
> >> > local_bh_enable() before cond_resched_tasks_rcu_qs() takes care about
> >> > them via a call to do_softirq().
> >> >
> >> > _ The time spent on other tasks after scheduling out, or on softirqs
> >> > processing, is spuriously accounted to the time limit.
> >> >
> >>
> >> That wasn't the case before ("rcu: Fix callbacks processing time limit
> >> retaining cond_resched()")
> >
> > But if cond_resched_tasks_rcu_qs() was called and then on the next iteration
> > tlimit is checked, the time spent scheduling out is included, right?
> >
>
> if tlimit was set, then that branch would either continue or break; both
> cases would have skipped over the cond_resched_tasks_rcu_qs() (which the
> aforementioned patch addresses).
Duh, right indeed. I need to clarify the changelog.
Thanks!
