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

[Hui Su]

On Thu, Sep 3, 2026 at 2:30 PM, Tim Chen wrote:
> On Thu, 2026-09-03 at 20:41 +0800, Chen, Yu C wrote:
> > Thanks for bringing this up. Previously Prateek has suggested to fix the
> > rq->donor issue [1] and unfortunately I missed the task_tick_cache() part.
> >
> > Regarding above line in the commit log, although I agree that
> > task_tick_numa() should be moved one level up, I did not quite get the
> > reason why sum_exec_runtime is mentioned here?
> > I guess what you mean is that, in task_tick_numa(), the
> > curr->se.sum_exec_runtime is used to check if there is a timeout to launch
> > the task_numa_work(), so curr->se.sum_exec_runtime has to be up-to-date.
> > With proxy execution, the se.sum_exec_runtime is only accumulated in
> > rq->curr rather than rq->donor, so passing a "paused"
> > rq->donor.sum_exec_runtime to task_tick_numa() is inaccurate?
>
> I think task_tick_core() needs to stay with the donor's context
> as it is the scheduling context.
>
> task_tick_core() is not about the execution context -- it decides
> whether the current scheduling context has used up enough of its slice
> to let a force-idled SMT sibling run. That slice belongs to the donor,
> so the donor is the right task to pass.
>
> There is a separate issue lurking here, task_tick_core() measures
> consumed slice as se->sum_exec_runtime - se->prev_sum_exec_runtime.
> Under proxy the donor's sum_exec_runtime does not advance, so that
> delta stays near zero and the force-idle resched may never trigger.
> Passing rq->curr does not fix it either. This is somewhat orthogonal
> to the issue that the execution context series is trying to solve.
> It should be fixed separately.
>
> I agree with you on this.

Hi Tim, Chenyu,

Thanks for the clarification.

The sum_exec_runtime paragraph was intended to point out that
task_tick_numa() uses execution runtime to drive NUMA scanning, but I
agree that this is too narrow. The more general reason is that
task_tick_numa() operates on execution-context state, including the task
and mm associated with the execution context. I'll reword the changelog
accordingly in v3.

For task_tick_core(), I agree that it should remain associated with the
donor, since the slice being evaluated belongs to the scheduling
context. The fact that the donor's sum_exec_runtime does not advance
under proxy execution is a separate issue, so I won't fold that into
this series.

I'll test the virtual-time prototype separately and follow up on that
issue independently if the approach holds up.

Thanks,
Hui