Re: [PATCH 2/2] sched/cache: Use execution context for cache task tick

From: Tim Chen

Date: Wed Sep 02 2026 - 16:35:53 EST


On Thu, 2026-09-03 at 00:33 +0800, Hui Su wrote:
> Cache-aware scheduling accounts CPU runtime to the mm of the task
> actually executing. update_se() passes rq->curr to account_mm_sched()
> for this purpose.
>
> With proxy execution, however, fair_sched_class::task_tick() receives
> rq->donor as its task argument. Passing that argument to task_tick_cache()
> can therefore queue cache_work and update the cache scan epoch for the
> donor's mm even though the corresponding CPU runtime is accounted to the
> execution context's mm.
>
> Use rq->curr for task_tick_cache() so cache scan work is driven for the
> same execution context whose runtime is accounted by account_mm_sched().
>
> Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing")
> Signed-off-by: Hui Su <sh_def@xxxxxxx>
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 09ddb3802c28..866f2a5dd101 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -15045,7 +15045,7 @@ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
> if (static_branch_unlikely(&sched_numa_balancing))
> task_tick_numa(rq, rq->curr);
>
> - task_tick_cache(rq, curr);
> + task_tick_cache(rq, rq->curr);

Thanks for raising this issue.
I agree that the execution context should be handed to task_tick_cache().

However, the donor may be a deadline or real time task, in which case
task_tick_fair() is not invoked at all -- and we still need
task_tick_cache(). Note that account_mm_sched() does run in that case,
via update_curr_common() -> update_se(), so rq->curr's mm keeps being
accounted while mm->sc_stat.epoch, which only task_tick_cache()
advances, goes stale. After llc_epoch_affinity_timeout epochs
account_mm_sched() then resets mm->sc_stat.cpu to -1 and we lose the
preferred LLC.

So maybe the check belongs one level up, in sched_tick().
There we can test whether rq->curr — the task actually running — is a
fair task, and call task_tick_cache() and task_tick_numa().
That test is the same p->sched_class != &fair_sched_class
one account_mm_sched() already does.

sched_tick_remote() would then need the same two calls added.
Without them, nohz_full CPUs would stop getting them at all.

Tim

>
> update_misfit_status(curr, rq);
> check_update_overutilized_status(task_rq(curr));