[PATCH v3 0/2] sched: Fix execution-context tick handling under proxy execution

[PATCH v3 0/2] sched: Fix execution-context tick handling under proxy execution

[Hui Su]

Proxy execution separates the scheduling context in rq->donor from the
execution context in rq->curr. Scheduler tick hooks which operate on
execution-context state must use rq->curr, while scheduling-context
state must continue to use the donor.

Move NUMA and cache task tick handling into a common execution-context
helper. This ensures that both hooks run when a fair task executes on
behalf of an RT or deadline donor, while the remaining fair-class tick
bookkeeping stays associated with the scheduling context.

Changes in v2 (since v1):
- Move NUMA and cache execution-context tick handling from
  task_tick_fair() to sched_tick().
- Invoke the hooks when rq->curr is a fair task, allowing them to run
  when the donor belongs to another scheduling class.
- Add the corresponding calls to sched_tick_remote() to preserve
  full-dynticks behavior.

Changes in v3 (since v2):
- Factor NUMA and cache execution-context tick handling into
  sched_tick_exec_ctx(), keeping sched_tick() and sched_tick_remote()
  in sync.
- Keep sched_tick_remote()'s existing curr-based scheduling-class
  dispatch unchanged and invoke the common helper afterward.
- Reword the NUMA rationale around execution-context state and the
  task/mm associated with the execution context, with sum_exec_runtime as
  supporting state rather than the sole reason for the change.
- Document why misfit, overutilized and core-scheduling tick handling
  remains associated with the scheduling context.
- Keep the task_tick_core() consumed-slice accounting issue discussed
  during review separate from this series.

Link: https://lore.kernel.org/r/20260903041154.2479761-1-sh_def@163.com

Tested with CONFIG_SCHED_PROXY_EXEC=y and all four NUMA/cache
configuration combinations, including W=1 scheduler object builds and
a full bzImage/modules build.  The first commit was also built
independently, and a CONFIG_NO_HZ_FULL=y kernel was built and booted.

A temporary QEMU proxy-mutex reproducer exercised both a normal FAIR
path and a FAIR execution task running on behalf of an SCHED_FIFO donor.
Using the same workload with QEMU 11.1.0 exposing two L3 domains, the
unpatched kernel did not invoke task_tick_numa() or task_tick_cache() for
the FAIR execution task during proxy execution.  With this series, both
hooks were repeatedly observed with rq->curr while rq->donor remained the
RT scheduling context.  NUMA task work was queued for the execution task;
cache work was also queued and its mm scan epoch advanced.  Three proxy
episodes completed, and the normal FAIR path was observed with
rq->curr == rq->donor.  The full-dynticks remote tick path was observed
invoking sched_tick_exec_ctx() on CPU 1.  No warnings, BUGs, oopses or
panics were observed.

The instrumentation and reproducer were kept outside this series.

Hui Su (2):
  sched/numa: Drive NUMA task tick from execution context
  sched/cache: Drive cache task tick from execution context

 kernel/sched/core.c  | 15 +++++++++++++++
 kernel/sched/fair.c  | 18 +++++++++---------
 kernel/sched/sched.h |  2 ++
 3 files changed, 26 insertions(+), 9 deletions(-)

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

[Hui Su]

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() operates on state associated with the task actually
executing, including its mm and NUMA work state. With proxy execution,
rq->donor provides the scheduling context while rq->curr identifies the
execution context.

Task-level execution runtime is likewise accounted to rq->curr, and
task_tick_numa() uses that runtime to drive periodic NUMA scanning.
Keeping task_tick_numa() under task_tick_fair() also means that it is not
invoked when a fair task executes on behalf of an RT or deadline donor.

Move NUMA tick handling into a scheduler helper for the execution
context, and invoke it from both sched_tick() and sched_tick_remote().

Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Suggested-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Hui Su <sh_def@163.com>
---
 kernel/sched/core.c  | 14 ++++++++++++++
 kernel/sched/fair.c  |  7 ++-----
 kernel/sched/sched.h |  1 +
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f78275192036..4db55e4ace9e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5762,6 +5762,17 @@ static int __init setup_resched_latency_warn_ms(char *str)
 }
 __setup("resched_latency_warn_ms=", setup_resched_latency_warn_ms);
 
+static void sched_tick_exec_ctx(struct rq *rq)
+{
+	struct task_struct *curr = rq->curr;
+
+	if (curr->sched_class != &fair_sched_class)
+		return;
+
+	if (static_branch_unlikely(&sched_numa_balancing))
+		task_tick_numa(rq, curr);
+}
+
 /*
  * This function gets called by the timer code, with HZ frequency.
  * We call it with interrupts disabled.
@@ -5794,6 +5805,8 @@ void sched_tick(void)
 		resched_curr(rq);
 
 	donor->sched_class->task_tick(rq, donor, 0);
+	sched_tick_exec_ctx(rq);
+
 	if (sched_feat(LATENCY_WARN))
 		resched_latency = cpu_resched_latency(rq);
 	calc_global_load_tick(rq);
@@ -5890,6 +5903,7 @@ static void sched_tick_remote(struct work_struct *work)
 				WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 30);
 			}
 			curr->sched_class->task_tick(rq, curr, 0);
+			sched_tick_exec_ctx(rq);
 
 			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);

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

[Chen Yu]

On Fri, Sep 04, 2026 at 04:52:43PM +0800, 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() operates on state associated with the task actually
> executing, including its mm and NUMA work state. With proxy execution,
> rq->donor provides the scheduling context while rq->curr identifies the
> execution context.
> 
> Task-level execution runtime is likewise accounted to rq->curr, and
> task_tick_numa() uses that runtime to drive periodic NUMA scanning.
> Keeping task_tick_numa() under task_tick_fair() also means that it is not
> invoked when a fair task executes on behalf of an RT or deadline donor.
> 
> Move NUMA tick handling into a scheduler helper for the execution
> context, and invoke it from both sched_tick() and sched_tick_remote().
> 

Both patches look good to me, let me launch a test and verify it works
as expected and report back later.

thanks,
Chenyu

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

[Tim Chen]

On Fri, 2026-09-04 at 16:52 +0800, 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() operates on state associated with the task actually
> executing, including its mm and NUMA work state. With proxy execution,
> rq->donor provides the scheduling context while rq->curr identifies the
> execution context.
> 
> Task-level execution runtime is likewise accounted to rq->curr, and
> task_tick_numa() uses that runtime to drive periodic NUMA scanning.
> Keeping task_tick_numa() under task_tick_fair() also means that it is not
> invoked when a fair task executes on behalf of an RT or deadline donor.
> 
> Move NUMA tick handling into a scheduler helper for the execution
> context, and invoke it from both sched_tick() and sched_tick_remote().
> 
> Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
> Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Suggested-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Hui Su <sh_def@163.com>
> ---
>  kernel/sched/core.c  | 14 ++++++++++++++
>  kernel/sched/fair.c  |  7 ++-----
>  kernel/sched/sched.h |  1 +
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f78275192036..4db55e4ace9e 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5762,6 +5762,17 @@ static int __init setup_resched_latency_warn_ms(char *str)
>  }
>  __setup("resched_latency_warn_ms=", setup_resched_latency_warn_ms);
>  
> +static void sched_tick_exec_ctx(struct rq *rq)

Just a minor nit.  We could consider putting sched_tick_exec_ctx()
in fair.c and export it instead.
That allows task_tick_numa() and task_tick_cache() declaration to
remain static.

No big deal either way.

Otherwise the two patches in the series look good to me.

Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>

Tim

> +{
> +	struct task_struct *curr = rq->curr;
> +
> +	if (curr->sched_class != &fair_sched_class)
> +		return;
> +
> +	if (static_branch_unlikely(&sched_numa_balancing))
> +		task_tick_numa(rq, curr);
> +}
> +
>  /*
>   * This function gets called by the timer code, with HZ frequency.
>   * We call it with interrupts disabled.
> @@ -5794,6 +5805,8 @@ void sched_tick(void)
>  		resched_curr(rq);
>  
>  	donor->sched_class->task_tick(rq, donor, 0);
> +	sched_tick_exec_ctx(rq);
> +
>  	if (sched_feat(LATENCY_WARN))
>  		resched_latency = cpu_resched_latency(rq);
>  	calc_global_load_tick(rq);
> @@ -5890,6 +5903,7 @@ static void sched_tick_remote(struct work_struct *work)
>  				WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 30);
>  			}
>  			curr->sched_class->task_tick(rq, curr, 0);
> +			sched_tick_exec_ctx(rq);
>  
>  			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);
> 

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

[Chen, Yu C]

On 9/4/2026 4:52 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() operates on state associated with the task actually
> executing, including its mm and NUMA work state. With proxy execution,
> rq->donor provides the scheduling context while rq->curr identifies the
> execution context.
> 
> Task-level execution runtime is likewise accounted to rq->curr, and
> task_tick_numa() uses that runtime to drive periodic NUMA scanning.
> Keeping task_tick_numa() under task_tick_fair() also means that it is not
> invoked when a fair task executes on behalf of an RT or deadline donor.
> 
> Move NUMA tick handling into a scheduler helper for the execution
> context, and invoke it from both sched_tick() and sched_tick_remote().
> 
> Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
> Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Suggested-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Hui Su <sh_def@163.com>

Per my understanding,

Reviewed-by: Chen Yu <yu.c.chen@intel.com>

thanks,
Chenyu

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

[Peter Zijlstra]

On Fri, Sep 04, 2026 at 04:52:43PM +0800, 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() operates on state associated with the task actually
> executing, including its mm and NUMA work state. With proxy execution,
> rq->donor provides the scheduling context while rq->curr identifies the
> execution context.
> 
> Task-level execution runtime is likewise accounted to rq->curr, and
> task_tick_numa() uses that runtime to drive periodic NUMA scanning.
> Keeping task_tick_numa() under task_tick_fair() also means that it is not
> invoked when a fair task executes on behalf of an RT or deadline donor.
> 
> Move NUMA tick handling into a scheduler helper for the execution
> context, and invoke it from both sched_tick() and sched_tick_remote().
> 
> Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
> Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Suggested-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Hui Su <sh_def@163.com>
> ---
>  kernel/sched/core.c  | 14 ++++++++++++++
>  kernel/sched/fair.c  |  7 ++-----
>  kernel/sched/sched.h |  1 +
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f78275192036..4db55e4ace9e 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5762,6 +5762,17 @@ static int __init setup_resched_latency_warn_ms(char *str)
>  }
>  __setup("resched_latency_warn_ms=", setup_resched_latency_warn_ms);
>  
> +static void sched_tick_exec_ctx(struct rq *rq)
> +{
> +	struct task_struct *curr = rq->curr;
> +
> +	if (curr->sched_class != &fair_sched_class)
> +		return;
> +
> +	if (static_branch_unlikely(&sched_numa_balancing))
> +		task_tick_numa(rq, curr);
> +}
> +
>  /*
>   * This function gets called by the timer code, with HZ frequency.
>   * We call it with interrupts disabled.
> @@ -5794,6 +5805,8 @@ void sched_tick(void)
>  		resched_curr(rq);
>  
>  	donor->sched_class->task_tick(rq, donor, 0);
> +	sched_tick_exec_ctx(rq);
> +
>  	if (sched_feat(LATENCY_WARN))
>  		resched_latency = cpu_resched_latency(rq);
>  	calc_global_load_tick(rq);
> @@ -5890,6 +5903,7 @@ static void sched_tick_remote(struct work_struct *work)
>  				WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 30);
>  			}
>  			curr->sched_class->task_tick(rq, curr, 0);
> +			sched_tick_exec_ctx(rq);
>  
>  			calc_load_nohz_remote(rq);
>  		}

So I'm not liking this, like at all. In fact, this is pretty terrible.

What about something like so?

---
 kernel/sched/core.c      | 16 +++++++++++++---
 kernel/sched/deadline.c  |  7 ++++++-
 kernel/sched/ext/ext.c   |  6 +++++-
 kernel/sched/fair.c      | 50 +++++++++++++++++++++++++++---------------------
 kernel/sched/idle.c      |  5 +++--
 kernel/sched/rt.c        |  6 +++++-
 kernel/sched/sched.h     |  2 +-
 kernel/sched/stop_task.c |  2 +-
 8 files changed, 62 insertions(+), 32 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 853afc869715..1f42bb856337 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -910,6 +910,16 @@ static void __used hrtick_clear(struct rq *rq)
 		hrtimer_cancel(&rq->hrtick_timer);
 }
 
+static inline void task_tick(struct rq *rq, int queued)
+{
+	const struct sched_class *curr_class = rq->curr->sched_class,
+				*donor_class = rq->donor->sched_class;
+
+	curr_class->task_tick(rq, queued);
+	if (sched_proxy_exec() && donor_class != curr_class)
+		donor_class->task_tick(rq, queued);
+}
+
 /*
  * High-resolution timer tick.
  * Runs from hardirq context with interrupts disabled.
@@ -923,7 +933,7 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer)
 
 	rq_lock(rq, &rf);
 	update_rq_clock(rq);
-	rq->donor->sched_class->task_tick(rq, rq->donor, 1);
+	task_tick(rq, 1);
 	rq_unlock(rq, &rf);
 
 	return HRTIMER_NORESTART;
@@ -5800,7 +5810,7 @@ void sched_tick(void)
 	if (dynamic_preempt_lazy() && tif_test_bit(TIF_NEED_RESCHED_LAZY))
 		resched_curr(rq);
 
-	donor->sched_class->task_tick(rq, donor, 0);
+	task_tick(rq, 0);
 	if (sched_feat(LATENCY_WARN))
 		resched_latency = cpu_resched_latency(rq);
 	calc_global_load_tick(rq);
@@ -5896,7 +5906,7 @@ static void sched_tick_remote(struct work_struct *work)
 				u64 delta = rq_clock_task(rq) - curr->se.exec_start;
 				WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 30);
 			}
-			curr->sched_class->task_tick(rq, curr, 0);
+			task_tick(rq, 0);
 
 			calc_load_nohz_remote(rq);
 		}
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index de6a361a87c7..65b83ff81201 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2876,8 +2876,13 @@ static void put_prev_task_dl(struct rq *rq, struct task_struct *p, struct task_s
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_dl(struct rq *rq, struct task_struct *p, int queued)
+static void task_tick_dl(struct rq *rq, int queued)
 {
+	struct task_struct *p = rq->donor;
+
+	if (p->sched_class != &dl_sched_class)
+		return;
+
 	update_curr_dl(rq);
 
 	update_dl_rq_load_avg(rq_clock_pelt(rq), rq, 1);
diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
index 51de1d8b72a1..5bae0c5b1b0d 100644
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@ -3789,10 +3789,14 @@ void scx_tick(struct rq *rq)
 	update_other_load_avgs(rq);
 }
 
-static void task_tick_scx(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_scx(struct rq *rq, int queued)
 {
+	struct task_struct *curr = rq->donor;
 	struct scx_sched *sch = scx_task_sched(curr);
 
+	if (donor->sched_class != &ext_sched_class)
+		return;
+
 	update_curr_scx(rq);
 
 	/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b8bd308c2d5b..f418135c505c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -15046,37 +15046,43 @@ static inline void task_tick_core(struct rq *rq, struct task_struct *curr) {}
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_fair(struct rq *rq, int queued)
 {
-	struct sched_entity *se = &curr->se;
+	struct task_struct *curr = rq->curr, *donor = rq->donor;
 
-	if (se->on_rq) {
-		unsigned long weight = NICE_0_LOAD;
-		struct cfs_rq *cfs_rq;
+	if (donor->sched_class == &fair_sched_class) {
+		struct sched_entity *se = &donor->se;
 
-		for_each_sched_entity(se) {
-			cfs_rq = cfs_rq_of(se);
-			entity_tick(cfs_rq, se, queued);
+		if (se->on_rq) {
+			unsigned long weight = NICE_0_LOAD;
+			struct cfs_rq *cfs_rq;
 
-			weight = __calc_prop_weight(cfs_rq, se, weight);
+			for_each_sched_entity(se) {
+				cfs_rq = cfs_rq_of(se);
+				entity_tick(cfs_rq, se, queued);
+
+				weight = __calc_prop_weight(cfs_rq, se, weight);
+			}
+
+			se = &donor->se;
+			reweight_eevdf(cfs_rq, se, weight, se->on_rq);
 		}
 
-		se = &curr->se;
-		reweight_eevdf(cfs_rq, se, weight, se->on_rq);
+		if (queued)
+			return;
+
+		update_misfit_status(donor, rq);
+		check_update_overutilized_status(task_rq(donor));
+
+		task_tick_core(rq, donor);
 	}
 
-	if (queued)
-		return;
+	if (curr->sched_class == &fair_sched_class) {
+		if (static_branch_unlikely(&sched_numa_balancing))
+			task_tick_numa(rq, curr);
 
-	if (static_branch_unlikely(&sched_numa_balancing))
-		task_tick_numa(rq, curr);
-
-	task_tick_cache(rq, curr);
-
-	update_misfit_status(curr, rq);
-	check_update_overutilized_status(task_rq(curr));
-
-	task_tick_core(rq, curr);
+		task_tick_cache(rq, curr);
+	}
 }
 
 /*
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index eb73b65ce6c4..077eed68869e 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -535,9 +535,10 @@ dequeue_task_idle(struct rq *rq, struct task_struct *p, int flags)
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_idle(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_idle(struct rq *rq, int queued)
 {
-	update_curr_idle(rq);
+	if (rq->donor->sched_class == &idle_sched_class)
+		update_curr_idle(rq);
 }
 
 static void switching_to_idle(struct rq *rq, struct task_struct *p)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 85303add726d..5e4ff18589c2 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2538,10 +2538,14 @@ static inline void watchdog(struct rq *rq, struct task_struct *p) { }
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued)
+static void task_tick_rt(struct rq *rq, int queued)
 {
+	struct task_struct *p = rq->donor;
 	struct sched_rt_entity *rt_se = &p->rt;
 
+	if (p->sched_class != &rt_sched_class)
+		return;
+
 	update_curr_rt(rq);
 	update_rt_rq_load_avg(rq_clock_pelt(rq), rq, 1);
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 6c3ad70e58b8..ca6ef6f0dcb4 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2727,7 +2727,7 @@ struct sched_class {
 	 * sched_tick: rq->lock
 	 * sched_tick_remote: rq->lock
 	 */
-	void (*task_tick)(struct rq *rq, struct task_struct *p, int queued);
+	void (*task_tick)(struct rq *rq, int queued);
 	/*
 	 * sched_cgroup_fork: p->pi_lock
 	 */
diff --git a/kernel/sched/stop_task.c b/kernel/sched/stop_task.c
index c909ca0d8c87..c3ad1eb4bc5f 100644
--- a/kernel/sched/stop_task.c
+++ b/kernel/sched/stop_task.c
@@ -71,7 +71,7 @@ static void put_prev_task_stop(struct rq *rq, struct task_struct *prev, struct t
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_stop(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_stop(struct rq *rq, int queued)
 {
 }
 

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

[Chen, Yu C]

On 9/8/2026 4:35 PM, Peter Zijlstra wrote:
> What about something like so?
> 

Thanks Peter for taking a look at this. I think this version achieves 
better decoupling
since the logic is added per scheduling class, rather than inserting 
random hooks into
the core scheduler.

> -static void task_tick_scx(struct rq *rq, struct task_struct *curr, int queued)
> +static void task_tick_scx(struct rq *rq, int queued)
>   {
> +	struct task_struct *curr = rq->donor;

struct task_struct *donor = rq->donor

>   	struct scx_sched *sch = scx_task_sched(curr);
>   
> +	if (donor->sched_class != &ext_sched_class)
> +		return;
> +
>   	update_curr_scx(rq);
>   
>   	/*

[ ... ]

> -static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
> +static void task_tick_fair(struct rq *rq, int queued)
>   {
> -	struct sched_entity *se = &curr->se;
> +	struct task_struct *curr = rq->curr, *donor = rq->donor;
>   
> -	if (se->on_rq) {
> -		unsigned long weight = NICE_0_LOAD;
> -		struct cfs_rq *cfs_rq;
> +	if (donor->sched_class == &fair_sched_class) {
> +		struct sched_entity *se = &donor->se;
>   
> -		for_each_sched_entity(se) {
> -			cfs_rq = cfs_rq_of(se);
> -			entity_tick(cfs_rq, se, queued);
> +		if (se->on_rq) {
> +			unsigned long weight = NICE_0_LOAD;
> +			struct cfs_rq *cfs_rq;
>   
> -			weight = __calc_prop_weight(cfs_rq, se, weight);
> +			for_each_sched_entity(se) {
> +				cfs_rq = cfs_rq_of(se);
> +				entity_tick(cfs_rq, se, queued);
> +
> +				weight = __calc_prop_weight(cfs_rq, se, weight);
> +			}
> +
> +			se = &donor->se;
> +			reweight_eevdf(cfs_rq, se, weight, se->on_rq);
>   		}
>   
> -		se = &curr->se;
> -		reweight_eevdf(cfs_rq, se, weight, se->on_rq);
> +		if (queued)
> +			return;
> +
> +		update_misfit_status(donor, rq);
> +		check_update_overutilized_status(task_rq(donor));
> +
> +		task_tick_core(rq, donor);
>   	}
>   
> -	if (queued)
> -		return;

The queued check might still be needed: if donor is not a fair task, we 
still
want to skip the numa balancing/sched_cache for hrtick event?
thanks,
Chenyu

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

[Peter Zijlstra]

On Tue, Sep 08, 2026 at 06:02:26PM +0800, Chen, Yu C wrote:
> On 9/8/2026 4:35 PM, Peter Zijlstra wrote:
> > What about something like so?
> > 
> 
> Thanks Peter for taking a look at this. I think this version achieves
> better decoupling since the logic is added per scheduling class,
> rather than inserting random hooks into the core scheduler.

Right :-)

> > -static void task_tick_scx(struct rq *rq, struct task_struct *curr, int queued)
> > +static void task_tick_scx(struct rq *rq, int queued)
> >   {
> > +	struct task_struct *curr = rq->donor;
> 
> struct task_struct *donor = rq->donor

Nah, it wants to be curr, like the argument was called before. I'll fix
that class check.

> >   	struct scx_sched *sch = scx_task_sched(curr);
> > +	if (donor->sched_class != &ext_sched_class)
> > +		return;
> > +
> >   	update_curr_scx(rq);
> >   	/*
> 
> [ ... ]
> 
> > -static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
> > +static void task_tick_fair(struct rq *rq, int queued)
> >   {
> > -	struct sched_entity *se = &curr->se;
> > +	struct task_struct *curr = rq->curr, *donor = rq->donor;
> > -	if (se->on_rq) {
> > -		unsigned long weight = NICE_0_LOAD;
> > -		struct cfs_rq *cfs_rq;
> > +	if (donor->sched_class == &fair_sched_class) {
> > +		struct sched_entity *se = &donor->se;
> > -		for_each_sched_entity(se) {
> > -			cfs_rq = cfs_rq_of(se);
> > -			entity_tick(cfs_rq, se, queued);
> > +		if (se->on_rq) {
> > +			unsigned long weight = NICE_0_LOAD;
> > +			struct cfs_rq *cfs_rq;
> > -			weight = __calc_prop_weight(cfs_rq, se, weight);
> > +			for_each_sched_entity(se) {
> > +				cfs_rq = cfs_rq_of(se);
> > +				entity_tick(cfs_rq, se, queued);
> > +
> > +				weight = __calc_prop_weight(cfs_rq, se, weight);
> > +			}
> > +
> > +			se = &donor->se;
> > +			reweight_eevdf(cfs_rq, se, weight, se->on_rq);
> >   		}
> > -		se = &curr->se;
> > -		reweight_eevdf(cfs_rq, se, weight, se->on_rq);
> > +		if (queued)
> > +			return;
> > +
> > +		update_misfit_status(donor, rq);
> > +		check_update_overutilized_status(task_rq(donor));
> > +
> > +		task_tick_core(rq, donor);
> >   	}
> > -	if (queued)
> > -		return;
> 
> The queued check might still be needed: if donor is not a fair task, we
> still
> want to skip the numa balancing/sched_cache for hrtick event?

Oh right. I have a patch pending that renames that thing. But yes, I
very much rushed this PoC patch without minding the details very much.

I also wondered if we should have task_tick() do curr_class->task_tick()
last, rather than first. But I couldn't immediately find a compelling
argument either way around.

Updated...

---
 kernel/sched/core.c      | 16 +++++++++++++---
 kernel/sched/deadline.c  |  7 ++++++-
 kernel/sched/ext/ext.c   |  6 +++++-
 kernel/sched/fair.c      | 49 ++++++++++++++++++++++++++----------------------
 kernel/sched/idle.c      |  5 +++--
 kernel/sched/rt.c        |  6 +++++-
 kernel/sched/sched.h     |  2 +-
 kernel/sched/stop_task.c |  2 +-
 8 files changed, 61 insertions(+), 32 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 853afc869715..1f42bb856337 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -910,6 +910,16 @@ static void __used hrtick_clear(struct rq *rq)
 		hrtimer_cancel(&rq->hrtick_timer);
 }
 
+static inline void task_tick(struct rq *rq, int queued)
+{
+	const struct sched_class *curr_class = rq->curr->sched_class,
+				*donor_class = rq->donor->sched_class;
+
+	curr_class->task_tick(rq, queued);
+	if (sched_proxy_exec() && donor_class != curr_class)
+		donor_class->task_tick(rq, queued);
+}
+
 /*
  * High-resolution timer tick.
  * Runs from hardirq context with interrupts disabled.
@@ -923,7 +933,7 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer)
 
 	rq_lock(rq, &rf);
 	update_rq_clock(rq);
-	rq->donor->sched_class->task_tick(rq, rq->donor, 1);
+	task_tick(rq, 1);
 	rq_unlock(rq, &rf);
 
 	return HRTIMER_NORESTART;
@@ -5800,7 +5810,7 @@ void sched_tick(void)
 	if (dynamic_preempt_lazy() && tif_test_bit(TIF_NEED_RESCHED_LAZY))
 		resched_curr(rq);
 
-	donor->sched_class->task_tick(rq, donor, 0);
+	task_tick(rq, 0);
 	if (sched_feat(LATENCY_WARN))
 		resched_latency = cpu_resched_latency(rq);
 	calc_global_load_tick(rq);
@@ -5896,7 +5906,7 @@ static void sched_tick_remote(struct work_struct *work)
 				u64 delta = rq_clock_task(rq) - curr->se.exec_start;
 				WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 30);
 			}
-			curr->sched_class->task_tick(rq, curr, 0);
+			task_tick(rq, 0);
 
 			calc_load_nohz_remote(rq);
 		}
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index de6a361a87c7..65b83ff81201 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2876,8 +2876,13 @@ static void put_prev_task_dl(struct rq *rq, struct task_struct *p, struct task_s
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_dl(struct rq *rq, struct task_struct *p, int queued)
+static void task_tick_dl(struct rq *rq, int queued)
 {
+	struct task_struct *p = rq->donor;
+
+	if (p->sched_class != &dl_sched_class)
+		return;
+
 	update_curr_dl(rq);
 
 	update_dl_rq_load_avg(rq_clock_pelt(rq), rq, 1);
diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
index 51de1d8b72a1..9c760d46f8dd 100644
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@ -3789,10 +3789,14 @@ void scx_tick(struct rq *rq)
 	update_other_load_avgs(rq);
 }
 
-static void task_tick_scx(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_scx(struct rq *rq, int queued)
 {
+	struct task_struct *curr = rq->donor;
 	struct scx_sched *sch = scx_task_sched(curr);
 
+	if (curr->sched_class != &ext_sched_class)
+		return;
+
 	update_curr_scx(rq);
 
 	/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b8bd308c2d5b..bbb239a22c5e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -15046,37 +15046,42 @@ static inline void task_tick_core(struct rq *rq, struct task_struct *curr) {}
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_fair(struct rq *rq, int queued)
 {
-	struct sched_entity *se = &curr->se;
+	struct task_struct *curr = rq->curr, *donor = rq->donor;
 
-	if (se->on_rq) {
-		unsigned long weight = NICE_0_LOAD;
-		struct cfs_rq *cfs_rq;
+	if (donor->sched_class == &fair_sched_class) {
+		struct sched_entity *se = &donor->se;
 
-		for_each_sched_entity(se) {
-			cfs_rq = cfs_rq_of(se);
-			entity_tick(cfs_rq, se, queued);
+		if (se->on_rq) {
+			unsigned long weight = NICE_0_LOAD;
+			struct cfs_rq *cfs_rq;
 
-			weight = __calc_prop_weight(cfs_rq, se, weight);
+			for_each_sched_entity(se) {
+				cfs_rq = cfs_rq_of(se);
+				entity_tick(cfs_rq, se, queued);
+
+				weight = __calc_prop_weight(cfs_rq, se, weight);
+			}
+
+			se = &donor->se;
+			reweight_eevdf(cfs_rq, se, weight, se->on_rq);
 		}
 
-		se = &curr->se;
-		reweight_eevdf(cfs_rq, se, weight, se->on_rq);
+		if (!queued) {
+			update_misfit_status(donor, rq);
+			check_update_overutilized_status(task_rq(donor));
+
+			task_tick_core(rq, donor);
+		}
 	}
 
-	if (queued)
-		return;
+	if (curr->sched_class == &fair_sched_class && !queued) {
+		if (static_branch_unlikely(&sched_numa_balancing))
+			task_tick_numa(rq, curr);
 
-	if (static_branch_unlikely(&sched_numa_balancing))
-		task_tick_numa(rq, curr);
-
-	task_tick_cache(rq, curr);
-
-	update_misfit_status(curr, rq);
-	check_update_overutilized_status(task_rq(curr));
-
-	task_tick_core(rq, curr);
+		task_tick_cache(rq, curr);
+	}
 }
 
 /*
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index eb73b65ce6c4..077eed68869e 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -535,9 +535,10 @@ dequeue_task_idle(struct rq *rq, struct task_struct *p, int flags)
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_idle(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_idle(struct rq *rq, int queued)
 {
-	update_curr_idle(rq);
+	if (rq->donor->sched_class == &idle_sched_class)
+		update_curr_idle(rq);
 }
 
 static void switching_to_idle(struct rq *rq, struct task_struct *p)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 85303add726d..5e4ff18589c2 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2538,10 +2538,14 @@ static inline void watchdog(struct rq *rq, struct task_struct *p) { }
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_rt(struct rq *rq, struct task_struct *p, int queued)
+static void task_tick_rt(struct rq *rq, int queued)
 {
+	struct task_struct *p = rq->donor;
 	struct sched_rt_entity *rt_se = &p->rt;
 
+	if (p->sched_class != &rt_sched_class)
+		return;
+
 	update_curr_rt(rq);
 	update_rt_rq_load_avg(rq_clock_pelt(rq), rq, 1);
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 6c3ad70e58b8..ca6ef6f0dcb4 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2727,7 +2727,7 @@ struct sched_class {
 	 * sched_tick: rq->lock
 	 * sched_tick_remote: rq->lock
 	 */
-	void (*task_tick)(struct rq *rq, struct task_struct *p, int queued);
+	void (*task_tick)(struct rq *rq, int queued);
 	/*
 	 * sched_cgroup_fork: p->pi_lock
 	 */
diff --git a/kernel/sched/stop_task.c b/kernel/sched/stop_task.c
index c909ca0d8c87..c3ad1eb4bc5f 100644
--- a/kernel/sched/stop_task.c
+++ b/kernel/sched/stop_task.c
@@ -71,7 +71,7 @@ static void put_prev_task_stop(struct rq *rq, struct task_struct *prev, struct t
  * and everything must be accessed through the @rq and @curr passed in
  * parameters.
  */
-static void task_tick_stop(struct rq *rq, struct task_struct *curr, int queued)
+static void task_tick_stop(struct rq *rq, int queued)
 {
 }
 

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

[Hui Su]

On Tue, Sep 08, 2026 at 12:44:07PM +0200, Peter Zijlstra wrote:
> I also wondered if we should have task_tick() do curr_class->task_tick()
> last, rather than first. But I couldn't immediately find a compelling
> argument either way around.
>
> Updated...
>
> @@ -910,6 +910,16 @@ static void __used hrtick_clear(struct rq *rq)
>  		hrtimer_cancel(&rq->hrtick_timer);
>  }
>
> +static inline void task_tick(struct rq *rq, int queued)
> +{
> +	const struct sched_class *curr_class = rq->curr->sched_class,
> +				*donor_class = rq->donor->sched_class;
> +
> +	curr_class->task_tick(rq, queued);
> +	if (sched_proxy_exec() && donor_class != curr_class)
> +		donor_class->task_tick(rq, queued);
> +}

The per-class split looks good to me. I noticed a couple of details while
going through the updated version.

First, I think there is a reason to call curr_class->task_tick() last.

For example, with an RT/DL donor and a FAIR execution context, the donor
class tick calls update_curr_*(), which goes through
update_curr_common()/update_se() and accounts the elapsed task runtime
to rq->curr->se.sum_exec_runtime. If the FAIR callback runs first,
task_tick_numa() observes sum_exec_runtime before the current tick's runtime
has been accounted.

Calling the donor class first preserves the accounting-before-consumer
ordering:

	donor_class->task_tick(rq, queued);
	if (sched_proxy_exec() && curr_class != donor_class)
		curr_class->task_tick(rq, queued);

This also matches the ordering in v3, where the donor tick ran before
sched_tick_exec_ctx().

Second, task_tick() is added after hrtick_clear(), which puts it inside
CONFIG_SCHED_HRTICK. Since sched_tick() calls task_tick() unconditionally,
CONFIG_SCHED_HRTICK=n would leave task_tick() undefined. The helper needs
to be outside the CONFIG_SCHED_HRTICK block.

With those changes, the split and the queued handling look good to me so far.
I'll test the cross-class and hrtick cases, rework the series accordingly,
and send a v4.

Thanks,
Hui

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

[Peter Zijlstra]

On Tue, Sep 08, 2026 at 09:10:21PM +0900, Hui Su wrote:
> On Tue, Sep 08, 2026 at 12:44:07PM +0200, Peter Zijlstra wrote:
> > I also wondered if we should have task_tick() do curr_class->task_tick()
> > last, rather than first. But I couldn't immediately find a compelling
> > argument either way around.
> >
> > Updated...
> >
> > @@ -910,6 +910,16 @@ static void __used hrtick_clear(struct rq *rq)
> >  		hrtimer_cancel(&rq->hrtick_timer);
> >  }
> >
> > +static inline void task_tick(struct rq *rq, int queued)
> > +{
> > +	const struct sched_class *curr_class = rq->curr->sched_class,
> > +				*donor_class = rq->donor->sched_class;
> > +
> > +	curr_class->task_tick(rq, queued);
> > +	if (sched_proxy_exec() && donor_class != curr_class)
> > +		donor_class->task_tick(rq, queued);
> > +}
> 
> The per-class split looks good to me. I noticed a couple of details while
> going through the updated version.
> 
> First, I think there is a reason to call curr_class->task_tick() last.
> 
> For example, with an RT/DL donor and a FAIR execution context, the donor
> class tick calls update_curr_*(), which goes through
> update_curr_common()/update_se() and accounts the elapsed task runtime
> to rq->curr->se.sum_exec_runtime. If the FAIR callback runs first,
> task_tick_numa() observes sum_exec_runtime before the current tick's runtime
> has been accounted.
> 
> Calling the donor class first preserves the accounting-before-consumer
> ordering:
> 
> 	donor_class->task_tick(rq, queued);
> 	if (sched_proxy_exec() && curr_class != donor_class)
> 		curr_class->task_tick(rq, queued);
> 
> This also matches the ordering in v3, where the donor tick ran before
> sched_tick_exec_ctx().

Indeed!

> Second, task_tick() is added after hrtick_clear(), which puts it inside
> CONFIG_SCHED_HRTICK. Since sched_tick() calls task_tick() unconditionally,
> CONFIG_SCHED_HRTICK=n would leave task_tick() undefined. The helper needs
> to be outside the CONFIG_SCHED_HRTICK block.

Whoopsie ;-)

> With those changes, the split and the queued handling look good to me so far.
> I'll test the cross-class and hrtick cases, rework the series accordingly,
> and send a v4.

Thanks!

[PATCH v3 2/2] sched/cache: Drive cache task tick from execution context

[Hui Su]

Cache-aware scheduling accounts CPU runtime to the mm of the task
actually executing. update_se() passes the execution task to
account_mm_sched() for this purpose.

With proxy execution, however, sched_tick() invokes task_tick() for the
scheduling context in rq->donor. task_tick_cache() is currently called
from task_tick_fair(), so it is skipped when a fair task executes on
behalf of an RT or deadline donor.

In that case account_mm_sched() continues to advance runtime accounting
for rq->curr, while task_tick_cache() does not advance the corresponding
mm scan epoch. Once the epoch becomes stale, account_mm_sched() can
invalidate the mm's preferred LLC.

Move cache tick handling into sched_tick_exec_ctx(), alongside NUMA tick
handling, and run it when the execution context is a fair task. Use the
same helper from sched_tick() and sched_tick_remote() so both tick paths
handle the execution context consistently.

Keep the remaining task_tick_fair() bookkeeping with its task argument,
since misfit, overutilized, and core scheduling state belong to the
scheduling context.

Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing")
Suggested-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Hui Su <sh_def@163.com>
---
 kernel/sched/core.c  |  1 +
 kernel/sched/fair.c  | 11 +++++++----
 kernel/sched/sched.h |  1 +
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4db55e4ace9e..7b8d4b06207d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5771,6 +5771,7 @@ static void sched_tick_exec_ctx(struct rq *rq)
 
 	if (static_branch_unlikely(&sched_numa_balancing))
 		task_tick_numa(rq, curr);
+	task_tick_cache(rq, curr);
 }
 
 /*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 55f0460e4ae3..c519bb193850 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1774,7 +1774,7 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
 	}
 }
 
-static void task_tick_cache(struct rq *rq, struct task_struct *p)
+void task_tick_cache(struct rq *rq, struct task_struct *p)
 {
 	struct callback_head *work = &p->cache_work;
 	struct mm_struct *mm = p->mm;
@@ -1996,7 +1996,7 @@ static inline void account_mm_sched(struct rq *rq, struct task_struct *p,
 
 void init_sched_mm(struct task_struct *p) { }
 
-static void task_tick_cache(struct rq *rq, struct task_struct *p) { }
+void task_tick_cache(struct rq *rq, struct task_struct *p) { }
 
 static inline int get_pref_llc(struct task_struct *p,
 			       struct mm_struct *mm)
@@ -15042,8 +15042,11 @@ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
 	if (queued)
 		return;
 
-	task_tick_cache(rq, curr);
-
+	/*
+	 * Misfit, overutilized and core scheduling state belong to the
+	 * scheduling context, and therefore stay with @curr rather than
+	 * rq->curr. See sched_tick_exec_ctx() for execution-context work.
+	 */
 	update_misfit_status(curr, rq);
 	check_update_overutilized_status(task_rq(curr));
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4d619f272b15..5d1f5ee47bf1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -4153,6 +4153,7 @@ 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);
+void task_tick_cache(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);

Re: [PATCH v3 2/2] sched/cache: Drive cache task tick from execution context

[Chen, Yu C]

On 9/4/2026 4:52 PM, Hui Su wrote:
> Cache-aware scheduling accounts CPU runtime to the mm of the task
> actually executing. update_se() passes the execution task to
> account_mm_sched() for this purpose.
> 
> With proxy execution, however, sched_tick() invokes task_tick() for the
> scheduling context in rq->donor. task_tick_cache() is currently called
> from task_tick_fair(), so it is skipped when a fair task executes on
> behalf of an RT or deadline donor.
> 
> In that case account_mm_sched() continues to advance runtime accounting
> for rq->curr, while task_tick_cache() does not advance the corresponding
> mm scan epoch. Once the epoch becomes stale, account_mm_sched() can
> invalidate the mm's preferred LLC.
> 
> Move cache tick handling into sched_tick_exec_ctx(), alongside NUMA tick
> handling, and run it when the execution context is a fair task. Use the
> same helper from sched_tick() and sched_tick_remote() so both tick paths
> handle the execution context consistently.
> 
> Keep the remaining task_tick_fair() bookkeeping with its task argument,
> since misfit, overutilized, and core scheduling state belong to the
> scheduling context.
> 
> Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing")
> Suggested-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Hui Su <sh_def@163.com>

Thanks for the fix,

Reviewed-by: Chen Yu <yu.c.chen@intel.com>

thanks,
Chenyu