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

["Chen, Yu C" <yu.c.chen@intel.com>]

Hi Su,

On 9/3/2026 12:11 PM, Hui Su wrote:
> Proxy execution separates the scheduling context in rq->donor from the
> execution context in rq->curr. sched_tick() invokes task_tick() for the
> donor's scheduling class.
> 
> task_tick_numa() is currently called from task_tick_fair(). This works
> when the donor is a fair task, but not when a fair task executes on
> behalf of an RT or deadline donor. In that case the donor's task_tick()
> still updates the execution task's sum_exec_runtime through
> update_curr_common(), but task_tick_fair() is not invoked and NUMA scan
> work for the execution task is not driven.

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, could you please elaborate a little more?
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?

But I also see that in task_tick_core(), the sum_exec_runtime is also 
leveraged
to calculate the delta "wall time" via __entity_slice_used():
se->sum_exec_runtime - se->prev_sum_exec_runtime
does it mean task_tick_core() also needs to be bring one level up to 
sched_tick()
and passed with rq->curr?

On the other hand, as Prateek mentioned in [1], it seems that 
sum_exec_runtime
might not the reason for passing rq->curr, but it could be:
"with "rq->curr->mm" being the one that is being used on CPU",
both sched_cache and NUMA balance fit Prateek's conclusion.

thanks,
Chenyu

[1]
https://lore.kernel.org/lkml/78c81f74-7b27-4f28-9ca2-0d1e27ed9c56@amd.com/

> 
> Move the NUMA tick handling one level up into sched_tick(), and invoke it
> when the execution context is a fair task.
> 
> Do the same in sched_tick_remote() so full-dynticks CPUs continue to
> receive NUMA tick handling after it is removed from task_tick_fair().
> 
> Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
> Suggested-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Hui Su <sh_def@163.com>
> ---
>   kernel/sched/core.c  | 9 +++++++++
>   kernel/sched/fair.c  | 7 ++-----
>   kernel/sched/sched.h | 1 +
>   3 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f78275192036..15fcc218d2fe 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5794,6 +5794,11 @@ void sched_tick(void)
>   		resched_curr(rq);
>   
>   	donor->sched_class->task_tick(rq, donor, 0);
> +
> +	if (rq->curr->sched_class == &fair_sched_class &&
> +	    static_branch_unlikely(&sched_numa_balancing))
> +		task_tick_numa(rq, rq->curr);
> +
>   	if (sched_feat(LATENCY_WARN))
>   		resched_latency = cpu_resched_latency(rq);
>   	calc_global_load_tick(rq);
> @@ -5891,6 +5896,10 @@ static void sched_tick_remote(struct work_struct *work)
>   			}
>   			curr->sched_class->task_tick(rq, curr, 0);
>   
> +			if (curr->sched_class == &fair_sched_class &&
> +			    static_branch_unlikely(&sched_numa_balancing))
> +				task_tick_numa(rq, curr);
> +
>   			calc_load_nohz_remote(rq);
>   		}
>   	}
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8dff37059faf..55f0460e4ae3 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4425,7 +4425,7 @@ void init_numa_balancing(u64 clone_flags, struct task_struct *p)
>   /*
>    * Drive the periodic memory faults..
>    */
> -static void task_tick_numa(struct rq *rq, struct task_struct *curr)
> +void task_tick_numa(struct rq *rq, struct task_struct *curr)
>   {
>   	struct callback_head *work = &curr->numa_work;
>   	u64 period, now;
> @@ -4491,7 +4491,7 @@ static void update_scan_period(struct task_struct *p, int new_cpu)
>   
>   #else /* !CONFIG_NUMA_BALANCING: */
>   
> -static void task_tick_numa(struct rq *rq, struct task_struct *curr)
> +void task_tick_numa(struct rq *rq, struct task_struct *curr)
>   {
>   }
>   
> @@ -15042,9 +15042,6 @@ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
>   	if (queued)
>   		return;
>   
> -	if (static_branch_unlikely(&sched_numa_balancing))
> -		task_tick_numa(rq, curr);
> -
>   	task_tick_cache(rq, curr);
>   
>   	update_misfit_status(curr, rq);
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index e656c7059bf8..4d619f272b15 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -4152,6 +4152,7 @@ extern void sched_cache_active_set(void);
>   void sched_domains_free_llc_id(int cpu);
>   
>   extern void init_sched_mm(struct task_struct *p);
> +void task_tick_numa(struct rq *rq, struct task_struct *p);
>   
>   extern u64 avg_vruntime(struct cfs_rq *cfs_rq);
>   extern int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se);