psi_account_irqtime() has two callers which share rq->psi_irq_time, and
they disagree about the context: __schedule() passes the outgoing rq->curr,
sched_tick() passes rq->donor.  Under proxy execution the donor is blocked
on a mutex while rq->curr burns the CPU.

The tick charges PSI_IRQ_FULL to the donor's cgroup and advances the
timestamp, so the call from __schedule() then finds delta <= 0 and charges
nothing.  The delta is not counted twice, it lands on the wrong cgroup.

Pass rq->curr, which is what the call read before commit af0c8b2bf67b
("sched: Split scheduler and execution contexts") renamed curr to donor
across sched_tick().  Without CONFIG_SCHED_PROXY_EXEC the two rq members
are a union, so this only changes anything where that option is set, and
it depends on EXPERT.

Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts")
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
---
Built and booted on x86_64 with CONFIG_SCHED_PROXY_EXEC=y, PSI and
IRQ_TIME_ACCOUNTING enabled, under x86_debug.config and panic_on_warn.
I did not construct a case where donor and curr differ.
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7885ff76e69f..2b48ae0ab372 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5791,7 +5791,7 @@ void sched_tick(void)
 	curr = rq->curr;
 	donor = rq->donor;
 
-	psi_account_irqtime(rq, donor, NULL);
+	psi_account_irqtime(rq, curr, NULL);
 
 	update_rq_clock(rq);
 	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));

base-commit: 5dd1818b15d98d4a20806cd00b1b40320b06004f
-- 
2.43.0

On Fri, Sep 18, 2026 at 09:29:15PM +0800, Zhan Xusheng wrote:
> psi_account_irqtime() has two callers which share rq->psi_irq_time, and
> they disagree about the context: __schedule() passes the outgoing rq->curr,
> sched_tick() passes rq->donor.  Under proxy execution the donor is blocked
> on a mutex while rq->curr burns the CPU.
> 
> The tick charges PSI_IRQ_FULL to the donor's cgroup and advances the
> timestamp, so the call from __schedule() then finds delta <= 0 and charges
> nothing.  The delta is not counted twice, it lands on the wrong cgroup.
> 
> Pass rq->curr, which is what the call read before commit af0c8b2bf67b
> ("sched: Split scheduler and execution contexts") renamed curr to donor
> across sched_tick().  Without CONFIG_SCHED_PROXY_EXEC the two rq members
> are a union, so this only changes anything where that option is set, and
> it depends on EXPERT.
> 
> Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts")
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> ---
> Built and booted on x86_64 with CONFIG_SCHED_PROXY_EXEC=y, PSI and
> IRQ_TIME_ACCOUNTING enabled, under x86_debug.config and panic_on_warn.
> I did not construct a case where donor and curr differ.
>  kernel/sched/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 7885ff76e69f..2b48ae0ab372 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5791,7 +5791,7 @@ void sched_tick(void)
>  	curr = rq->curr;
>  	donor = rq->donor;
>  
> -	psi_account_irqtime(rq, donor, NULL);
> +	psi_account_irqtime(rq, curr, NULL);
>  
>  	update_rq_clock(rq);
>  	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));

Does not in fact apply. There is no curr in sched_tick anymore.

On Tue, Sep 22, 2026 at 10:17:06AM +0200, Peter Zijlstra wrote:
> Does not in fact apply. There is no curr in sched_tick anymore.

It needs commit f5741d2b3451 ("sched/core: Call wq_worker_tick() for the
execution context"), which added that local.  That is in sched/urgent and
master, not in sched/core, and the patch applies cleanly to the first two.

If you want it on sched/core instead, I will resend using rq->curr at the
call site.

On Tue, Sep 22, 2026 at 05:15:31PM +0800, Zhan Xusheng wrote:
> On Tue, Sep 22, 2026 at 10:17:06AM +0200, Peter Zijlstra wrote:
> > Does not in fact apply. There is no curr in sched_tick anymore.
> 
> It needs commit f5741d2b3451 ("sched/core: Call wq_worker_tick() for the
> execution context"), which added that local.  That is in sched/urgent and
> master, not in sched/core, and the patch applies cleanly to the first two.
> 
> If you want it on sched/core instead, I will resend using rq->curr at the
> call site.

Hmm, I thought I was on tip/master which should have /urgent on, but let
me try again. Perhaps I fat-fingered something.

On Tue, Sep 22, 2026 at 11:49:44AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 22, 2026 at 05:15:31PM +0800, Zhan Xusheng wrote:
> > On Tue, Sep 22, 2026 at 10:17:06AM +0200, Peter Zijlstra wrote:
> > > Does not in fact apply. There is no curr in sched_tick anymore.
> > 
> > It needs commit f5741d2b3451 ("sched/core: Call wq_worker_tick() for the
> > execution context"), which added that local.  That is in sched/urgent and
> > master, not in sched/core, and the patch applies cleanly to the first two.
> > 
> > If you want it on sched/core instead, I will resend using rq->curr at the
> > call site.
> 
> Hmm, I thought I was on tip/master which should have /urgent on, but let
> me try again. Perhaps I fat-fingered something.

And indeed. I must've done something weird this morning. In it goes.

On Fri, Sep 18, 2026 at 6:29 AM Zhan Xusheng <zhanxusheng1024@gmail.com> wrote:
>
> psi_account_irqtime() has two callers which share rq->psi_irq_time, and
> they disagree about the context: __schedule() passes the outgoing rq->curr,
> sched_tick() passes rq->donor.  Under proxy execution the donor is blocked
> on a mutex while rq->curr burns the CPU.
>
> The tick charges PSI_IRQ_FULL to the donor's cgroup and advances the
> timestamp, so the call from __schedule() then finds delta <= 0 and charges
> nothing.  The delta is not counted twice, it lands on the wrong cgroup.
>
> Pass rq->curr, which is what the call read before commit af0c8b2bf67b
> ("sched: Split scheduler and execution contexts") renamed curr to donor
> across sched_tick().  Without CONFIG_SCHED_PROXY_EXEC the two rq members
> are a union, so this only changes anything where that option is set, and
> it depends on EXPERT.
>
> Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts")
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>

Thank you for finding this, and thank you to Hui Su for testing it!

Acked-by: John Stultz <jstultz@google.com>

thanks
-john

> I did not construct a case where donor and curr differ.

I tested two proxy-execution processes in separate cgroup v2 cgroups.
The owner held a CPU0 mutex for 20s; a SCHED_FIFO donor blocked on it.
On x86_64 QEMU (4 vCPUs, 2 GiB), with PSI and IRQ time accounting enabled,
the irq.pressure total deltas (us) were:
  unpatched: owner 22,053, donor 401,127
  patched:   owner 552,740, donor 31,566
Both runs completed successfully, and attribution moved to execution context.
This exercises the donor != curr case missing from the original test.

Tested-by: Hui Su <sh_def@163.com>

The following commit has been merged into the sched/urgent branch of tip:

Commit-ID:     a0bb6fac53fa7cf1cadb487b43d4c9276a6b82e3
Gitweb:        https://git.kernel.org/tip/a0bb6fac53fa7cf1cadb487b43d4c9276a6b82e3
Author:        Zhan Xusheng <zhanxusheng1024@gmail.com>
AuthorDate:    Fri, 18 Sep 2026 21:29:15 +08:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 24 Sep 2026 10:32:50 +02:00

sched/core: Account PSI IRQ time to the execution context, not the scheduling context

psi_account_irqtime() has two callers which share rq->psi_irq_time, and
they disagree about the context: __schedule() passes the outgoing rq->curr,
sched_tick() passes rq->donor.  Under proxy execution the donor is blocked
on a mutex while rq->curr burns the CPU.

The tick charges PSI_IRQ_FULL to the donor's cgroup and advances the
timestamp, so the call from __schedule() then finds delta <= 0 and charges
nothing.  The delta is not counted twice, it lands on the wrong cgroup.

Pass rq->curr, which is what the call read before commit af0c8b2bf67b
("sched: Split scheduler and execution contexts") renamed 'curr' to
'donor' across sched_tick().  Without CONFIG_SCHED_PROXY_EXEC the two rq
members are a union, so this only changes anything where that option is set,
and it depends on EXPERT.

Fixes: af0c8b2bf67b ("sched: Split scheduler and execution contexts")
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20260918132915.1236312-1-zhanxusheng@xiaomi.com
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0b846a1..1fe40de 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5798,7 +5798,7 @@ void sched_tick(void)
 	curr = rq->curr;
 	donor = rq->donor;
 
-	psi_account_irqtime(rq, donor, NULL);
+	psi_account_irqtime(rq, curr, NULL);
 
 	update_rq_clock(rq);
 	hw_pressure = arch_scale_hw_pressure(cpu_of(rq));