[PATCH 1/2] sched/numa: Use execution context for NUMA task tick

[PATCH 1/2] sched/numa: Use execution context for NUMA task tick

[Hui Su]

With proxy execution, fair_sched_class::task_tick() receives the
scheduling context in rq->donor, while rq->curr identifies the task
that is actually executing.

NUMA tick handling is tied to the execution context. In particular,
task_tick_numa() uses the task's sum_exec_runtime to drive periodic
scans and queues numa_work against that task and its mm.

Proxy execution runtime accounting deliberately charges sum_exec_runtime
to rq->curr rather than rq->donor. Passing the donor to task_tick_numa()
therefore drives NUMA scanning from a task whose runtime is not being
advanced by proxy execution, while the executing task's NUMA state is
not driven by the tick.

Use rq->curr when invoking task_tick_numa() so the runtime, mm and
task_work all belong to the execution context.

Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts")
Signed-off-by: Hui Su <sh_def@163.com>

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8dff37059faf..09ddb3802c28 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -15043,7 +15043,7 @@ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
 		return;
 
 	if (static_branch_unlikely(&sched_numa_balancing))
-		task_tick_numa(rq, curr);
+		task_tick_numa(rq, rq->curr);
 
 	task_tick_cache(rq, curr);
 
-- 
2.54.0

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

[Hui Su]

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);
 
 	update_misfit_status(curr, rq);
 	check_update_overutilized_status(task_rq(curr));
-- 
2.54.0

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

[Tim Chen]

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));

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

[Hui Su]

On Wed, 2026-09-02 at 13:12 -0700, Tim Chen wrote:
> 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

Thanks for the review. I agree with your analysis.

The v1 cache change only passed rq->curr to task_tick_cache() from
task_tick_fair(), which still misses the case where a fair execution task
runs on behalf of an RT or deadline donor. In that case task_tick_fair()
is not invoked, although update_curr_common() still accounts execution
runtime to rq->curr.

I have reworked the series to move task_tick_numa() and task_tick_cache()
out of task_tick_fair() and invoke them from sched_tick() when rq->curr
is a fair task. The corresponding calls are also added to
sched_tick_remote() so full-dynticks CPUs continue to receive both ticks.
The calls remain after the donor scheduling-class tick to preserve the
existing runtime-accounting order.

I tested this with a QEMU topology providing two LLCs. With an RT donor and a
fair mutex owner, the unmodified kernel did not execute the cache tick during
the proxy execution episode. With the change, task_tick_cache() was observed
with p == rq->curr while rq->donor was a different RT task. The proxy test
completed three episodes without warnings or errors.

The default build passed, as did builds with NUMA balancing and cache
scheduling disabled independently and together. I also built the affected
objects with CONFIG_NO_HZ_FULL=y.

I will send v2 with these changes.

Thanks,
Hui