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

[Tim Chen <tim.c.chen@linux.intel.com>]

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@163.com>
> 
> 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));