* [PATCH v3 0/2] sched: Fix execution-context tick handling under proxy execution
@ 2026-09-04 8:52 Hui Su
2026-09-04 8:52 ` [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context Hui Su
2026-09-04 8:52 ` [PATCH v3 2/2] sched/cache: Drive cache " Hui Su
0 siblings, 2 replies; 12+ messages in thread
From: Hui Su @ 2026-09-04 8:52 UTC (permalink / raw)
To: peterz, mingo, tim.c.chen, yu.c.chen, kprateek.nayak
Cc: juri.lelli, vincent.guittot, dietmar.eggemann, rostedt, bsegall,
mgorman, vschneid, connoro, jstultz, linux-kernel
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(-)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-04 8:52 [PATCH v3 0/2] sched: Fix execution-context tick handling under proxy execution Hui Su
@ 2026-09-04 8:52 ` Hui Su
2026-09-04 15:52 ` Chen Yu
` (3 more replies)
2026-09-04 8:52 ` [PATCH v3 2/2] sched/cache: Drive cache " Hui Su
1 sibling, 4 replies; 12+ messages in thread
From: Hui Su @ 2026-09-04 8:52 UTC (permalink / raw)
To: peterz, mingo, tim.c.chen, yu.c.chen, kprateek.nayak
Cc: juri.lelli, vincent.guittot, dietmar.eggemann, rostedt, bsegall,
mgorman, vschneid, connoro, jstultz, linux-kernel
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);
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 2/2] sched/cache: Drive cache task tick from execution context
2026-09-04 8:52 [PATCH v3 0/2] sched: Fix execution-context tick handling under proxy execution Hui Su
2026-09-04 8:52 ` [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context Hui Su
@ 2026-09-04 8:52 ` Hui Su
2026-09-08 7:45 ` Chen, Yu C
1 sibling, 1 reply; 12+ messages in thread
From: Hui Su @ 2026-09-04 8:52 UTC (permalink / raw)
To: peterz, mingo, tim.c.chen, yu.c.chen, kprateek.nayak
Cc: juri.lelli, vincent.guittot, dietmar.eggemann, rostedt, bsegall,
mgorman, vschneid, connoro, jstultz, linux-kernel
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);
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-04 8:52 ` [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context Hui Su
@ 2026-09-04 15:52 ` Chen Yu
2026-09-04 17:17 ` Tim Chen
` (2 subsequent siblings)
3 siblings, 0 replies; 12+ messages in thread
From: Chen Yu @ 2026-09-04 15:52 UTC (permalink / raw)
To: Hui Su
Cc: peterz, mingo, tim.c.chen, kprateek.nayak, juri.lelli,
vincent.guittot, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, connoro, jstultz, linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-04 8:52 ` [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context Hui Su
2026-09-04 15:52 ` Chen Yu
@ 2026-09-04 17:17 ` Tim Chen
2026-09-08 7:40 ` Chen, Yu C
2026-09-08 8:35 ` Peter Zijlstra
3 siblings, 0 replies; 12+ messages in thread
From: Tim Chen @ 2026-09-04 17:17 UTC (permalink / raw)
To: Hui Su, peterz, mingo, yu.c.chen, kprateek.nayak
Cc: juri.lelli, vincent.guittot, dietmar.eggemann, rostedt, bsegall,
mgorman, vschneid, connoro, jstultz, linux-kernel
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);
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-04 8:52 ` [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context Hui Su
2026-09-04 15:52 ` Chen Yu
2026-09-04 17:17 ` Tim Chen
@ 2026-09-08 7:40 ` Chen, Yu C
2026-09-08 8:35 ` Peter Zijlstra
3 siblings, 0 replies; 12+ messages in thread
From: Chen, Yu C @ 2026-09-08 7:40 UTC (permalink / raw)
To: Hui Su
Cc: peterz, kprateek.nayak, tim.c.chen, juri.lelli, vincent.guittot,
dietmar.eggemann, rostedt, bsegall, mgorman, vschneid, connoro,
jstultz, linux-kernel, mingo, chen.yu
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 2/2] sched/cache: Drive cache task tick from execution context
2026-09-04 8:52 ` [PATCH v3 2/2] sched/cache: Drive cache " Hui Su
@ 2026-09-08 7:45 ` Chen, Yu C
0 siblings, 0 replies; 12+ messages in thread
From: Chen, Yu C @ 2026-09-08 7:45 UTC (permalink / raw)
To: Hui Su
Cc: peterz, kprateek.nayak, mingo, tim.c.chen, juri.lelli,
vincent.guittot, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, jstultz, linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-04 8:52 ` [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context Hui Su
` (2 preceding siblings ...)
2026-09-08 7:40 ` Chen, Yu C
@ 2026-09-08 8:35 ` Peter Zijlstra
2026-09-08 10:02 ` Chen, Yu C
3 siblings, 1 reply; 12+ messages in thread
From: Peter Zijlstra @ 2026-09-08 8:35 UTC (permalink / raw)
To: Hui Su
Cc: mingo, tim.c.chen, yu.c.chen, kprateek.nayak, juri.lelli,
vincent.guittot, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, connoro, jstultz, linux-kernel, arighi
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)
{
}
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-08 8:35 ` Peter Zijlstra
@ 2026-09-08 10:02 ` Chen, Yu C
2026-09-08 10:44 ` Peter Zijlstra
0 siblings, 1 reply; 12+ messages in thread
From: Chen, Yu C @ 2026-09-08 10:02 UTC (permalink / raw)
To: Peter Zijlstra, Hui Su
Cc: mingo, tim.c.chen, kprateek.nayak, juri.lelli, vincent.guittot,
dietmar.eggemann, rostedt, bsegall, mgorman, vschneid, connoro,
jstultz, linux-kernel, arighi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-08 10:02 ` Chen, Yu C
@ 2026-09-08 10:44 ` Peter Zijlstra
2026-09-08 12:10 ` Hui Su
0 siblings, 1 reply; 12+ messages in thread
From: Peter Zijlstra @ 2026-09-08 10:44 UTC (permalink / raw)
To: Chen, Yu C
Cc: Hui Su, mingo, tim.c.chen, kprateek.nayak, juri.lelli,
vincent.guittot, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, connoro, jstultz, linux-kernel, arighi
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)
{
}
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-08 10:44 ` Peter Zijlstra
@ 2026-09-08 12:10 ` Hui Su
2026-09-09 8:37 ` Peter Zijlstra
0 siblings, 1 reply; 12+ messages in thread
From: Hui Su @ 2026-09-08 12:10 UTC (permalink / raw)
To: Peter Zijlstra, Chen, Yu C, tim.c.chen
Cc: mingo, kprateek.nayak, juri.lelli, vincent.guittot,
dietmar.eggemann, rostedt, bsegall, mgorman, vschneid, connoro,
jstultz, linux-kernel, arighi
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context
2026-09-08 12:10 ` Hui Su
@ 2026-09-09 8:37 ` Peter Zijlstra
0 siblings, 0 replies; 12+ messages in thread
From: Peter Zijlstra @ 2026-09-09 8:37 UTC (permalink / raw)
To: Hui Su
Cc: Chen, Yu C, tim.c.chen, mingo, kprateek.nayak, juri.lelli,
vincent.guittot, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, connoro, jstultz, linux-kernel, arighi
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!
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2026-09-09 8:37 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-04 8:52 [PATCH v3 0/2] sched: Fix execution-context tick handling under proxy execution Hui Su
2026-09-04 8:52 ` [PATCH v3 1/2] sched/numa: Drive NUMA task tick from execution context Hui Su
2026-09-04 15:52 ` Chen Yu
2026-09-04 17:17 ` Tim Chen
2026-09-08 7:40 ` Chen, Yu C
2026-09-08 8:35 ` Peter Zijlstra
2026-09-08 10:02 ` Chen, Yu C
2026-09-08 10:44 ` Peter Zijlstra
2026-09-08 12:10 ` Hui Su
2026-09-09 8:37 ` Peter Zijlstra
2026-09-04 8:52 ` [PATCH v3 2/2] sched/cache: Drive cache " Hui Su
2026-09-08 7:45 ` Chen, Yu C
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®