Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Sep 08, 2026 at 09:10:21PM +0900, Hui Su wrote:
> On Tue, Sep 08, 2026 at 12:44:07PM +0200, Peter Zijlstra wrote:
> > I also wondered if we should have task_tick() do curr_class->task_tick()
> > last, rather than first. But I couldn't immediately find a compelling
> > argument either way around.
> >
> > Updated...
> >
> > @@ -910,6 +910,16 @@ static void __used hrtick_clear(struct rq *rq)
> >  		hrtimer_cancel(&rq->hrtick_timer);
> >  }
> >
> > +static inline void task_tick(struct rq *rq, int queued)
> > +{
> > +	const struct sched_class *curr_class = rq->curr->sched_class,
> > +				*donor_class = rq->donor->sched_class;
> > +
> > +	curr_class->task_tick(rq, queued);
> > +	if (sched_proxy_exec() && donor_class != curr_class)
> > +		donor_class->task_tick(rq, queued);
> > +}
> 
> The per-class split looks good to me. I noticed a couple of details while
> going through the updated version.
> 
> First, I think there is a reason to call curr_class->task_tick() last.
> 
> For example, with an RT/DL donor and a FAIR execution context, the donor
> class tick calls update_curr_*(), which goes through
> update_curr_common()/update_se() and accounts the elapsed task runtime
> to rq->curr->se.sum_exec_runtime. If the FAIR callback runs first,
> task_tick_numa() observes sum_exec_runtime before the current tick's runtime
> has been accounted.
> 
> Calling the donor class first preserves the accounting-before-consumer
> ordering:
> 
> 	donor_class->task_tick(rq, queued);
> 	if (sched_proxy_exec() && curr_class != donor_class)
> 		curr_class->task_tick(rq, queued);
> 
> This also matches the ordering in v3, where the donor tick ran before
> sched_tick_exec_ctx().

Indeed!

> Second, task_tick() is added after hrtick_clear(), which puts it inside
> CONFIG_SCHED_HRTICK. Since sched_tick() calls task_tick() unconditionally,
> CONFIG_SCHED_HRTICK=n would leave task_tick() undefined. The helper needs
> to be outside the CONFIG_SCHED_HRTICK block.

Whoopsie ;-)

> With those changes, the split and the queued handling look good to me so far.
> I'll test the cross-class and hrtick cases, rework the series accordingly,
> and send a v4.

Thanks!