[RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution

[RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution

[K Prateek Nayak]

When booting into a kernel with CONFIG_SCHED_PROXY_EXEC and CONFIG_PSI,
a inconsistent task state warning was noticed soon after the boot
similar to:

    psi: inconsistent task state! task=... cpu=... psi_flags=4 clear=0 set=4

On analysis, the following sequence of event was found to be the cause
of the splat:

o Blocked task is retained on the runqueue.
o psi_sched_switch() sees task_on_rq_queued() and retains the runnable
  signals for the task.
o Tasks blocks later via proxy_deactivate() but psi_dequeue() doesn't
  adjust the PSI flags since DEQUEUE_SLEEP is set expecting
  psi_sched_switch() to fix the signals.
o The blocked task is woken up with the PSI state still reflecting that
  the task is runnable (TSK_RUNNING) leading to the splat.


Simply tracking proxy_deactivate() is not enough since the task's
blocked_on relationship can be cleared remotely without acquiring the
runqueue lock which can force a blocked task to run before a wakeup -
pick_next_task() pickes the blocked donor and since blocked on
relationship was cleared remotely, task_is_blocked() returns false
leading to the task being run on the CPU.

If the task blocks again before it is woken up, psi_sched_switch() will
try to clear the runnable signals (TSK_RUNNING) unconditionally leading
to a different splat similar to:

    psi: inconsistent task state! task=... cpu=... psi_flags=10 clear=14 set=0


To get around this, track the complete lifecycle of a blocked doner
right from delaying the deactivation to the wakeup. When in
blocked/donor state, PSI will consider these tasks similar to delayed
tasks - blocked but migratable.

When the ttwu_runnable() finally wakeups up the task, or if the donor is
deactivated via proxy_deactivate(), the proxy indicator is cleared to
show that the task is either fully blocked or fully runnable now.

Patch 1 and 2 were cleanups to make life slightly easier when auditing
the implementation and inspecting the debug logs. Patch 3 to 5 implement
the tracking of donor states and a couple of fixes on top.

Series was tested on top of tip:sched/core for a while running
sched-messaging without observing any inconsistent task state warning
and should apply cleanly on top of:

    git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core

at commit 33cf66d88306 ("sched/fair: Proportional newidle balance").

---
K Prateek Nayak (5):
  sched/psi: Make psi stubs consistent for !CONFIG_PSI
  sched/psi: Prepend "0x" to format specifiers when printing PSI flags
  sched/core: Track blocked tasks retained on rq for proxy
  sched/core: Block proxy task on pick when blocked_on is cleared before
    wakeup
  sched/psi: Fix PSI signals of blocked tasks retained for proxy

 include/linux/sched.h |  4 +++
 kernel/sched/core.c   | 59 +++++++++++++++++++++++++++++++++++++++++--
 kernel/sched/psi.c    |  4 +--
 kernel/sched/sched.h  |  2 ++
 kernel/sched/stats.h  |  6 ++---
 5 files changed, 68 insertions(+), 7 deletions(-)


base-commit: 33cf66d88306663d16e4759e9d24766b0aaa2e17
-- 
2.34.1

[PATCH 1/5] sched/psi: Make psi stubs consistent for !CONFIG_PSI

[K Prateek Nayak]

commit 1a6151017ee5 ("sched: psi: pass enqueue/dequeue flags to psi
callbacks directly") modified the psi_enqueue() and psi_dequeue()
functions to take the complete enqueue/dequeue flags but left the stubs
for !CONFIG_PSI unaltered.

Modify the stubs to also accept the flags argument to keep it consistent
with CONFIG_PSI.

Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
 kernel/sched/stats.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index cbf7206b3f9d..3323d773fec3 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -221,8 +221,8 @@ static inline void psi_sched_switch(struct task_struct *prev,
 }
 
 #else /* !CONFIG_PSI: */
-static inline void psi_enqueue(struct task_struct *p, bool migrate) {}
-static inline void psi_dequeue(struct task_struct *p, bool migrate) {}
+static inline void psi_enqueue(struct task_struct *p, int flags) {}
+static inline void psi_dequeue(struct task_struct *p, int flags) {}
 static inline void psi_ttwu_dequeue(struct task_struct *p) {}
 static inline void psi_sched_switch(struct task_struct *prev,
 				    struct task_struct *next,
-- 
2.34.1

[PATCH 2/5] sched/psi: Prepend "0x" to format specifiers when printing PSI flags

[K Prateek Nayak]

It is not immediately clear that the PSI flags, the set, and the clear
bits printed in PSI warnings are hexadecimal values. Prepend "0x" to
format specifiers to make it clear.

Since "kernel/sched" uses "0x%x" as opposed to "%#x" when printing
hexadecimal values, the same was followed to keep consistency.

Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
 kernel/sched/psi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 59fdb7ebbf22..b031608c02ce 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -830,7 +830,7 @@ static void psi_group_change(struct psi_group *group, int cpu,
 		if (groupc->tasks[t]) {
 			groupc->tasks[t]--;
 		} else if (!psi_bug) {
-			printk_deferred(KERN_ERR "psi: task underflow! cpu=%d t=%d tasks=[%u %u %u %u] clear=%x set=%x\n",
+			printk_deferred(KERN_ERR "psi: task underflow! cpu=%d t=%d tasks=[%u %u %u %u] clear=0x%x set=0x%x\n",
 					cpu, t, groupc->tasks[0],
 					groupc->tasks[1], groupc->tasks[2],
 					groupc->tasks[3], clear, set);
@@ -896,7 +896,7 @@ static void psi_flags_change(struct task_struct *task, int clear, int set)
 	if (((task->psi_flags & set) ||
 	     (task->psi_flags & clear) != clear) &&
 	    !psi_bug) {
-		printk_deferred(KERN_ERR "psi: inconsistent task state! task=%d:%s cpu=%d psi_flags=%x clear=%x set=%x\n",
+		printk_deferred(KERN_ERR "psi: inconsistent task state! task=%d:%s cpu=%d psi_flags=0x%x clear=0x%x set=0x%x\n",
 				task->pid, task->comm, task_cpu(task),
 				task->psi_flags, clear, set);
 		psi_bug = 1;
-- 
2.34.1

[RFC PATCH 3/5] sched/core: Track blocked tasks retained on rq for proxy

[K Prateek Nayak]

Track blocked task retained on runqueue to act as a proxy donor. This is
necessary since task's "blocked_on" relationship can be cleared without
holding the task_rq lock and a blocked donor can be forced to run on CPU
before a wakeup since task_is_blocked() returns false at the time of pick.

This is necessary for to fix a PSI task state corruption observed with
CONFIG_SCHED_PROXY_EXEC=y but it also serves as a medium to track the
lifecycle of proxy donor when it is retained on the rq for proxy.

Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
 include/linux/sched.h |  4 ++++
 kernel/sched/core.c   | 32 +++++++++++++++++++++++++++++++-
 kernel/sched/sched.h  |  2 ++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index bb436ee1942d..f96ad1ec680b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -978,6 +978,10 @@ struct task_struct {
 	unsigned			sched_contributes_to_load:1;
 	unsigned			sched_migrated:1;
 	unsigned			sched_task_hot:1;
+#ifdef CONFIG_SCHED_PROXY_EXEC
+	/* To indicate blocked task was retained on the rq for proxy. */
+	unsigned			sched_proxy:1;
+#endif
 
 	/* Force alignment to the next boundary: */
 	unsigned			:0;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9f10cfbdc228..52a744beeca9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3659,6 +3659,9 @@ ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags,
 	}
 }
 
+static inline void set_task_proxy(struct task_struct *p);
+static inline void clear_task_proxy(struct task_struct *p);
+
 /*
  * Consider @p being inside a wait loop:
  *
@@ -3693,6 +3696,8 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
 	rq = __task_rq_lock(p, &rf);
 	if (task_on_rq_queued(p)) {
 		update_rq_clock(rq);
+		if (is_proxy_task(p))
+			clear_task_proxy(p);
 		if (p->se.sched_delayed)
 			enqueue_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_DELAYED);
 		if (!task_on_cpu(rq, p)) {
@@ -6460,8 +6465,10 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p,
 	 * blocked on a mutex, and we want to keep it on the runqueue
 	 * to be selectable for proxy-execution.
 	 */
-	if (!should_block)
+	if (!should_block) {
+		set_task_proxy(p);
 		return false;
+	}
 
 	p->sched_contributes_to_load =
 		(task_state & TASK_UNINTERRUPTIBLE) &&
@@ -6487,6 +6494,23 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p,
 }
 
 #ifdef CONFIG_SCHED_PROXY_EXEC
+bool is_proxy_task(struct task_struct *p)
+{
+	return !!p->sched_proxy;
+}
+
+static inline void set_task_proxy(struct task_struct *p)
+{
+	WARN_ON_ONCE(p->sched_proxy);
+	p->sched_proxy = 1;
+}
+
+static inline void clear_task_proxy(struct task_struct *p)
+{
+	WARN_ON_ONCE(!p->sched_proxy);
+	p->sched_proxy = 0;
+}
+
 static inline struct task_struct *proxy_resched_idle(struct rq *rq)
 {
 	put_prev_set_next_task(rq, rq->donor, rq->idle);
@@ -6502,6 +6526,9 @@ static bool __proxy_deactivate(struct rq *rq, struct task_struct *donor)
 	/* Don't deactivate if the state has been changed to TASK_RUNNING */
 	if (state == TASK_RUNNING)
 		return false;
+
+	clear_task_proxy(donor);
+
 	/*
 	 * Because we got donor from pick_next_task(), it is *crucial*
 	 * that we call proxy_resched_idle() before we deactivate it.
@@ -6649,6 +6676,9 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
 	return owner;
 }
 #else /* SCHED_PROXY_EXEC */
+bool is_proxy_task(struct task_struct *p) { return false; }
+static inline void set_task_proxy(struct task_struct *p) { }
+static inline void clear_task_proxy(p) { }
 static struct task_struct *
 find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
 {
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b419a4d98461..fa2a2d5bff6d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1362,6 +1362,8 @@ static inline u32 sched_rng(void)
 #define cpu_curr(cpu)		(cpu_rq(cpu)->curr)
 #define raw_rq()		raw_cpu_ptr(&runqueues)
 
+bool is_proxy_task(struct task_struct *p);
+
 #ifdef CONFIG_SCHED_PROXY_EXEC
 static inline void rq_set_donor(struct rq *rq, struct task_struct *t)
 {
-- 
2.34.1

[RFC PATCH 4/5] sched/core: Block proxy task on pick when blocked_on is cleared before wakeup

[K Prateek Nayak]

Task's "blocked_on" relationship can be cleared remotely without
acquiring the task's runqueue lock and can lead to a blocked donor being
picked to run without having a wakeup.

Although this is not a problem since the task blocks back again if it
wasn't woken up in time, it cause problem from stats acccounting point,
especially for PSI since psi_enqueue() tries to reset the runnable
signals for a proxy task that wasn't fully block, and psi_sched_switch()
assumes a blocking task is always runnable before being switched out.

When investigating PSI task state corruption, the following transitions
were observed with CONFIG_SCHED_PROXY_EXEC=y:

   ... [141] ...: psi_flags_change: task=4358:... cpu=141 psi_flags=14 clear=14 set=0 queued=1 delayed=0 blocked=1 psi_bug=0

   # Task is retained on the rq for proxy. All runnable signals are
   # cleared for the task.

   ... [141] ...: psi_flags_change: task=4358:... cpu=141 psi_flags=0 clear=0 set=10 queued=1 delayed=0 blocked=0 psi_bug=0

   # Task is picked and forced to run since task_is_blocked() returns
   # false.

   ... [141] ...: psi_dequeue: task=4358:... cpu=141 psi_flags=10

   # Task blocks again. Flag modifications are deferred to
   # psi_sched_switch() since DEQUEUE_SLEEP.

   ... [141] ...: psi_flags_change: task=4358:... cpu=141 psi_flags=10 clear=14 set=0 queued=1 delayed=1 blocked=0 psi_bug=(0 -> 1)

   # psi_sched_switch() tries to clear TSK_ONCPU and TSK_RUNNING.
   # TSK_RUNNING was never set since task was never woken up.
   # !! PSI inconsistent state waring triggered !!

   ... [014] ...: try_to_wake_up: wakeup: task=4358: psi_flags=0 queued=0 delayed=0 blocked=0

   # Task wakes up and is finally runnable.

To prevent any inconsistencies from running a task that was supposed to
be blocked, deactivate a potential donor task if it was picked without
having the "sched_proxy" indicator cleared. A pending wakeup would queue
the task back again when it turns runnable again.

Fixes: be41bde4c3a8 ("sched: Add an initial sketch of the find_proxy_task() function")
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
 kernel/sched/core.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 52a744beeca9..d6265f38e93a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6679,6 +6679,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
 bool is_proxy_task(struct task_struct *p) { return false; }
 static inline void set_task_proxy(struct task_struct *p) { }
 static inline void clear_task_proxy(p) { }
+static bool __proxy_deactivate(struct rq *rq, struct task_struct *donor) { return false; }
 static struct task_struct *
 find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
 {
@@ -6839,6 +6840,25 @@ static void __sched notrace __schedule(int sched_mode)
 		if (next == rq->idle)
 			goto keep_resched;
 	}
+	if (unlikely(is_proxy_task(next))) {
+		/*
+		 * It is possible for a remote CPU to clear task
+		 * "blocked_on" without acquiring the task rq lock.
+		 *
+		 * This can lead to a blocked task retained for proxy to
+		 * be forced on CPU without the task being woken up
+		 * since task_is_blocked(next) above returns false.
+		 *
+		 * Since "sched_proxy" is only cleared on wakeup,
+		 * is_proxy_task() returning true indicates that the
+		 * task hasn't woken up yet.
+		 *
+		 * Block the task and wait for wakeup to queue it back
+		 * when it is runnable again.
+		 */
+		if (__proxy_deactivate(rq, next))
+			goto pick_again;
+	}
 picked:
 	clear_tsk_need_resched(prev);
 	clear_preempt_need_resched();
-- 
2.34.1

[RFC PATCH 5/5] sched/psi: Fix PSI signals of blocked tasks retained for proxy

[K Prateek Nayak]

Booting a machine with CONFIG_SCHED_PROXY_EXEC=y leads to a PSI warning
similar to following early into the boot:

    psi: inconsistent task state! task=... cpu=... psi_flags=4 clear=0 set=4

Investigating the set of events that led to warning indicated that
psi_sched_switch() never dequeued the signals for a blocked task since
it was retained on the runqueue as a potential donor but the
psi_enqueue() that follows the wakeup tries to re-enqueue these signals
for the blocked tasks thus leading to the inconsistent state warning.

When fixing PSI state corruption for delayed dequeue in commit
c6508124193d ("sched/psi: Fix mistaken CPU pressure indication after
corrupted task state bug"), Johannes mentioned that delayed tasks are
in-fact blocked and the PSI signals should treat them as such in [1].

With proxy execution, the same argument holds true for blocked tasks
that are kept around to donate the vruntime context - the tasks are
essentially blocked and their PSI signals should be treated as such
until they are woken up again.

Treat is_proxy_task() as blocked for psi_sched_switch() and call
psi_enqueue(ENQUEUE_WAKEUP) when the "sched_proxy" signal is cleared.
For all the transitions in-between, treat the task similar to a delayed
task and just move the block signals on migration of blocked donor.

Fixes: be41bde4c3a8 ("sched: Add an initial sketch of the find_proxy_task() function")
Link: https://lore.kernel.org/all/20241010130316.GA181795@cmpxchg.org/ [1]
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
 kernel/sched/core.c  | 9 +++++++--
 kernel/sched/stats.h | 2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d6265f38e93a..765365b81b12 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3696,8 +3696,12 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
 	rq = __task_rq_lock(p, &rf);
 	if (task_on_rq_queued(p)) {
 		update_rq_clock(rq);
-		if (is_proxy_task(p))
+		if (is_proxy_task(p)) {
 			clear_task_proxy(p);
+			/* Task was never fully blocked to be delayed. */
+			WARN_ON_ONCE(p->se.sched_delayed);
+			psi_enqueue(p, ENQUEUE_WAKEUP);
+		}
 		if (p->se.sched_delayed)
 			enqueue_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_DELAYED);
 		if (!task_on_cpu(rq, p)) {
@@ -6903,7 +6907,8 @@ static void __sched notrace __schedule(int sched_mode)
 
 		psi_account_irqtime(rq, prev, next);
 		psi_sched_switch(prev, next, !task_on_rq_queued(prev) ||
-					     prev->se.sched_delayed);
+					     prev->se.sched_delayed ||
+					     is_proxy_task(prev));
 
 		trace_sched_switch(preempt, prev, next, prev_state);
 
diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
index 3323d773fec3..b2d7461c1ea9 100644
--- a/kernel/sched/stats.h
+++ b/kernel/sched/stats.h
@@ -142,7 +142,7 @@ static inline void psi_enqueue(struct task_struct *p, int flags)
 	if (task_on_cpu(task_rq(p), p))
 		return;
 
-	if (p->se.sched_delayed) {
+	if (p->se.sched_delayed || is_proxy_task(p)) {
 		/* CPU migration of "sleeping" task */
 		WARN_ON_ONCE(!(flags & ENQUEUE_MIGRATED));
 		if (p->in_memstall)
-- 
2.34.1

Re: [RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution

[John Stultz]

On Mon, Nov 17, 2025 at 10:56 AM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>
> When booting into a kernel with CONFIG_SCHED_PROXY_EXEC and CONFIG_PSI,
> a inconsistent task state warning was noticed soon after the boot
> similar to:
>
>     psi: inconsistent task state! task=... cpu=... psi_flags=4 clear=0 set=4
>
> On analysis, the following sequence of event was found to be the cause
> of the splat:
>
> o Blocked task is retained on the runqueue.
> o psi_sched_switch() sees task_on_rq_queued() and retains the runnable
>   signals for the task.
> o Tasks blocks later via proxy_deactivate() but psi_dequeue() doesn't
>   adjust the PSI flags since DEQUEUE_SLEEP is set expecting
>   psi_sched_switch() to fix the signals.
> o The blocked task is woken up with the PSI state still reflecting that
>   the task is runnable (TSK_RUNNING) leading to the splat.

Hey, K Prateek!
  Thanks for chasing this down and sending this series out!

I'm still getting my head around the description above (its been
awhile since I last looked at the PSI code), but early on I often hit
PSI splats, and I thought I had addressed it with the patch here:
  https://github.com/johnstultz-work/linux-dev/commit/f60923a6176b3778a8fc9b9b0bbe4953153ce565

And with that I've not run across any warnings since.

Now, I hadn't tripped over the issue recently with the subset of the
full series I've been pushing upstream, and as I most easily ran into
it with the sleeping owner enqueuing feature I was holding the fix
back for those changes. But I realize unfortunately CONFIG_PSI at some
point got disabled in my test defconfig, so I've not had the
opportunity to trip it, and sure enough I can trivially see it booting
with the current upstream code.

Applying that fix does seem to avoid the warnings in my trivial
testing, but again I've not dug through the logic in awhile, so you
may have a better sense of the inadequacies of that fix.

If it looks reasonable to you, I'll rework the commit message so it
isn't so focused on the sleeping-owner-enquing case and submit it.

I'll have to spend some time here looking more at your proposed
solution. On the initial glance, I do fret a little with the
task->sched_proxy bit overlapping a bit in meaning with the
task->blocked_on value.

thanks
-john

Re: [PATCH 1/5] sched/psi: Make psi stubs consistent for !CONFIG_PSI

[John Stultz]

On Mon, Nov 17, 2025 at 10:56 AM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>
> commit 1a6151017ee5 ("sched: psi: pass enqueue/dequeue flags to psi
> callbacks directly") modified the psi_enqueue() and psi_dequeue()
> functions to take the complete enqueue/dequeue flags but left the stubs
> for !CONFIG_PSI unaltered.
>
> Modify the stubs to also accept the flags argument to keep it consistent
> with CONFIG_PSI.
>
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>

I'm not super deep in the PSI logic, but this looks obviously correct.
Thanks for cleaning this up.
Reviewed-by: John Stultz <jstultz@google.com>

Re: [PATCH 2/5] sched/psi: Prepend "0x" to format specifiers when printing PSI flags

[John Stultz]

On Mon, Nov 17, 2025 at 10:56 AM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>
> It is not immediately clear that the PSI flags, the set, and the clear
> bits printed in PSI warnings are hexadecimal values. Prepend "0x" to
> format specifiers to make it clear.
>
> Since "kernel/sched" uses "0x%x" as opposed to "%#x" when printing
> hexadecimal values, the same was followed to keep consistency.
>
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>

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

Re: [RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution

[K Prateek Nayak]

Hello John,

On 11/18/2025 6:15 AM, John Stultz wrote:
> On Mon, Nov 17, 2025 at 10:56 AM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>>
>> When booting into a kernel with CONFIG_SCHED_PROXY_EXEC and CONFIG_PSI,
>> a inconsistent task state warning was noticed soon after the boot
>> similar to:
>>
>>     psi: inconsistent task state! task=... cpu=... psi_flags=4 clear=0 set=4
>>
>> On analysis, the following sequence of event was found to be the cause
>> of the splat:
>>
>> o Blocked task is retained on the runqueue.
>> o psi_sched_switch() sees task_on_rq_queued() and retains the runnable
>>   signals for the task.
>> o Tasks blocks later via proxy_deactivate() but psi_dequeue() doesn't
>>   adjust the PSI flags since DEQUEUE_SLEEP is set expecting
>>   psi_sched_switch() to fix the signals.
>> o The blocked task is woken up with the PSI state still reflecting that
>>   the task is runnable (TSK_RUNNING) leading to the splat.
> 
> Hey, K Prateek!
>   Thanks for chasing this down and sending this series out!
> 
> I'm still getting my head around the description above (its been
> awhile since I last looked at the PSI code), but early on I often hit
> PSI splats, and I thought I had addressed it with the patch here:
>   https://github.com/johnstultz-work/linux-dev/commit/f60923a6176b3778a8fc9b9b0bbe4953153ce565

Oooo! Let me go test that.

> 
> And with that I've not run across any warnings since.
> 
> Now, I hadn't tripped over the issue recently with the subset of the
> full series I've been pushing upstream, and as I most easily ran into
> it with the sleeping owner enqueuing feature I was holding the fix
> back for those changes. But I realize unfortunately CONFIG_PSI at some
> point got disabled in my test defconfig, so I've not had the
> opportunity to trip it, and sure enough I can trivially see it booting
> with the current upstream code.

I hit this on tip:sched/core when looking at the recent sched_yield()
changes. Maybe the "blocked_on" serialization with the proxy migration
will make this all go away :)

> 
> Applying that fix does seem to avoid the warnings in my trivial
> testing, but again I've not dug through the logic in awhile, so you
> may have a better sense of the inadequacies of that fix.
> 
> If it looks reasonable to you, I'll rework the commit message so it
> isn't so focused on the sleeping-owner-enquing case and submit it.

That would be great! And it seems to be a lot more simpler than the
the stuff I'm trying to do. I'll give it a spin and get back to you.
Thank you again for pointing to the fix.

> 
> I'll have to spend some time here looking more at your proposed
> solution. On the initial glance, I do fret a little with the
> task->sched_proxy bit overlapping a bit in meaning with the
> task->blocked_on value.

Ack! I'm pretty sure with the blocked_on locking we'll not have these
"interesting" situations but I posted the RFC out just in case we
needed something in the interim but turns out its a solved problem :)

On last thing, it'll be good to get some clarification on how to treat
the blocked tasks retained on the runqueue for PSI - quick look at your
fix suggests we still consider them runnable (TSK_RUNNING) from PSI
standpoint - is this ideal or should PSI consider these tasks blocked?

-- 
Thanks and Regards,
Prateek

Re: [RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution

[John Stultz]

On Mon, Nov 17, 2025 at 5:39 PM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
> On 11/18/2025 6:15 AM, John Stultz wrote:
> > I'm still getting my head around the description above (its been
> > awhile since I last looked at the PSI code), but early on I often hit
> > PSI splats, and I thought I had addressed it with the patch here:
> >   https://github.com/johnstultz-work/linux-dev/commit/f60923a6176b3778a8fc9b9b0bbe4953153ce565
>
> Oooo! Let me go test that.
>
> >
> > And with that I've not run across any warnings since.
> >
> > Now, I hadn't tripped over the issue recently with the subset of the
> > full series I've been pushing upstream, and as I most easily ran into
> > it with the sleeping owner enqueuing feature I was holding the fix
> > back for those changes. But I realize unfortunately CONFIG_PSI at some
> > point got disabled in my test defconfig, so I've not had the
> > opportunity to trip it, and sure enough I can trivially see it booting
> > with the current upstream code.
>
> I hit this on tip:sched/core when looking at the recent sched_yield()
> changes. Maybe the "blocked_on" serialization with the proxy migration
> will make this all go away :)
>
> >
> > Applying that fix does seem to avoid the warnings in my trivial
> > testing, but again I've not dug through the logic in awhile, so you
> > may have a better sense of the inadequacies of that fix.
> >
> > If it looks reasonable to you, I'll rework the commit message so it
> > isn't so focused on the sleeping-owner-enquing case and submit it.
>
> That would be great! And it seems to be a lot more simpler than the
> the stuff I'm trying to do. I'll give it a spin and get back to you.
> Thank you again for pointing to the fix.
>
> >
> > I'll have to spend some time here looking more at your proposed
> > solution. On the initial glance, I do fret a little with the
> > task->sched_proxy bit overlapping a bit in meaning with the
> > task->blocked_on value.
>
> Ack! I'm pretty sure with the blocked_on locking we'll not have these
> "interesting" situations but I posted the RFC out just in case we
> needed something in the interim but turns out its a solved problem :)
>
> On last thing, it'll be good to get some clarification on how to treat
> the blocked tasks retained on the runqueue for PSI - quick look at your
> fix suggests we still consider them runnable (TSK_RUNNING) from PSI
> standpoint - is this ideal or should PSI consider these tasks blocked?

So my default way of thinking about mutex-blocked tasks with proxy is
that they are equivalent to runnable. They can be selected by
pick_next_task(), and they are charged for the time they donate to the
lock-owner that runs as the proxy.
To conceptualize things with ProxyExec, I often imagine the
mutex-blocked task as being in "optimistic spin" mode waiting for the
mutex, where we'd just run the task and let it spin, instead of
blocking the task (when the lock owner isn't already running). Then we
just have the optimization of instead of just wasting time spinning,
we run the lock owner to release the lock.

So, I need to further refresh myself with more of the subtleties of
PSI, but to me considering it TSK_RUNNING seems intuitive.

There are maybe some transient cases, like where the blocked task is
on one RQ, and the lock holder is on another, and thus until the
blocked task is selected (and then proxy-migrated to boost the task on
the other cpu), where if it were very far back in the runqueue it
could be contributing what could be seen as "false pressure" on that
RQ.  So maybe I need to think a bit more about that. But it still is a
task that wants to run to boost the lock owner, so I'm not sure how
different it is in the PSI view compared to transient runqueue
imbalances.

thanks
-john

Re: [RFC PATCH 3/5] sched/core: Track blocked tasks retained on rq for proxy

[K Prateek Nayak]

On 11/18/2025 12:25 AM, K Prateek Nayak wrote:
> @@ -6649,6 +6676,9 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
>  	return owner;
>  }
>  #else /* SCHED_PROXY_EXEC */
> +bool is_proxy_task(struct task_struct *p) { return false; }
> +static inline void set_task_proxy(struct task_struct *p) { }
> +static inline void clear_task_proxy(p) { }

I clearly messed that up for !CONFIG_SCHED_PROXY_EXEC

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 765365b81b12..d51c35e26d80 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6682,7 +6682,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
 #else /* SCHED_PROXY_EXEC */
 bool is_proxy_task(struct task_struct *p) { return false; }
 static inline void set_task_proxy(struct task_struct *p) { }
-static inline void clear_task_proxy(p) { }
+static inline void clear_task_proxy(struct task_struct *p) { }
 static bool __proxy_deactivate(struct rq *rq, struct task_struct *donor) { return false; }
 static struct task_struct *
 find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)


>  static struct task_struct *
>  find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
>  {
-- 
Thanks and Regards,
Prateek

Re: [RFC PATCH 0/5] sched/psi: Fix PSI accounting with proxy execution

[K Prateek Nayak]

Hello John,

On 11/18/2025 9:56 AM, John Stultz wrote:
> On Mon, Nov 17, 2025 at 5:39 PM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>> On 11/18/2025 6:15 AM, John Stultz wrote:
>>> I'm still getting my head around the description above (its been
>>> awhile since I last looked at the PSI code), but early on I often hit
>>> PSI splats, and I thought I had addressed it with the patch here:
>>>   https://github.com/johnstultz-work/linux-dev/commit/f60923a6176b3778a8fc9b9b0bbe4953153ce565
>>
>> Oooo! Let me go test that.

Seems like that solution works too on top of current tip:sched/core.
I think you can send it out as a standalone patch for inclusion while
we hash out the donor migration bits (and blocked owner, and rwsem!).

>>
>>>
>>> And with that I've not run across any warnings since.
>>>
>>> Now, I hadn't tripped over the issue recently with the subset of the
>>> full series I've been pushing upstream, and as I most easily ran into
>>> it with the sleeping owner enqueuing feature I was holding the fix
>>> back for those changes. But I realize unfortunately CONFIG_PSI at some
>>> point got disabled in my test defconfig, so I've not had the
>>> opportunity to trip it, and sure enough I can trivially see it booting
>>> with the current upstream code.
>>
>> I hit this on tip:sched/core when looking at the recent sched_yield()
>> changes. Maybe the "blocked_on" serialization with the proxy migration
>> will make this all go away :)
>>
>>>
>>> Applying that fix does seem to avoid the warnings in my trivial
>>> testing, but again I've not dug through the logic in awhile, so you
>>> may have a better sense of the inadequacies of that fix.
>>>
>>> If it looks reasonable to you, I'll rework the commit message so it
>>> isn't so focused on the sleeping-owner-enquing case and submit it.
>>
>> That would be great! And it seems to be a lot more simpler than the
>> the stuff I'm trying to do. I'll give it a spin and get back to you.
>> Thank you again for pointing to the fix.
>>
>>>
>>> I'll have to spend some time here looking more at your proposed
>>> solution. On the initial glance, I do fret a little with the
>>> task->sched_proxy bit overlapping a bit in meaning with the
>>> task->blocked_on value.
>>
>> Ack! I'm pretty sure with the blocked_on locking we'll not have these
>> "interesting" situations but I posted the RFC out just in case we
>> needed something in the interim but turns out its a solved problem :)
>>
>> On last thing, it'll be good to get some clarification on how to treat
>> the blocked tasks retained on the runqueue for PSI - quick look at your
>> fix suggests we still consider them runnable (TSK_RUNNING) from PSI
>> standpoint - is this ideal or should PSI consider these tasks blocked?
> 
> So my default way of thinking about mutex-blocked tasks with proxy is
> that they are equivalent to runnable. They can be selected by
> pick_next_task(), and they are charged for the time they donate to the
> lock-owner that runs as the proxy.
> To conceptualize things with ProxyExec, I often imagine the
> mutex-blocked task as being in "optimistic spin" mode waiting for the
> mutex, where we'd just run the task and let it spin, instead of
> blocking the task (when the lock owner isn't already running). Then we
> just have the optimization of instead of just wasting time spinning,
> we run the lock owner to release the lock.

I think I can see it now. I generally considered them the other
way around as blocked tasks retained just for the vruntime context.
I'll try changing my perspective to match yours when looking at
proxy :)

As for the fix in your tree, feel free to include:

Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>

> 
> So, I need to further refresh myself with more of the subtleties of
> PSI, but to me considering it TSK_RUNNING seems intuitive.
> 
> There are maybe some transient cases, like where the blocked task is
> on one RQ, and the lock holder is on another, and thus until the
> blocked task is selected (and then proxy-migrated to boost the task on
> the other cpu), where if it were very far back in the runqueue it
> could be contributing what could be seen as "false pressure" on that
> RQ.  So maybe I need to think a bit more about that. But it still is a
> task that wants to run to boost the lock owner, so I'm not sure how
> different it is in the PSI view compared to transient runqueue
> imbalances.

I think Johannes has a better understanding of how these signals are
used in the field so I'll defer to him.

-- 
Thanks and Regards,
Prateek

Re: [PATCH 1/5] sched/psi: Make psi stubs consistent for !CONFIG_PSI

[Madadi Vineeth Reddy]

On 18/11/25 00:25, K Prateek Nayak wrote:
> commit 1a6151017ee5 ("sched: psi: pass enqueue/dequeue flags to psi
> callbacks directly") modified the psi_enqueue() and psi_dequeue()
> functions to take the complete enqueue/dequeue flags but left the stubs
> for !CONFIG_PSI unaltered.
> 
> Modify the stubs to also accept the flags argument to keep it consistent
> with CONFIG_PSI.
> 
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> ---
>  kernel/sched/stats.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
> index cbf7206b3f9d..3323d773fec3 100644
> --- a/kernel/sched/stats.h
> +++ b/kernel/sched/stats.h
> @@ -221,8 +221,8 @@ static inline void psi_sched_switch(struct task_struct *prev,
>  }
>  
>  #else /* !CONFIG_PSI: */
> -static inline void psi_enqueue(struct task_struct *p, bool migrate) {}
> -static inline void psi_dequeue(struct task_struct *p, bool migrate) {}
> +static inline void psi_enqueue(struct task_struct *p, int flags) {}
> +static inline void psi_dequeue(struct task_struct *p, int flags) {}
>  static inline void psi_ttwu_dequeue(struct task_struct *p) {}
>  static inline void psi_sched_switch(struct task_struct *prev,
>  				    struct task_struct *next,

Right. The commit that updated the function signature did not update the
!CONFIG_PSI stubs accordingly. This patch corrects that.

Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>

Thanks,
Vineeth

Re: [PATCH 1/5] sched/psi: Make psi stubs consistent for !CONFIG_PSI

[K Prateek Nayak]

Hello Vineeth,

On 11/20/2025 11:29 AM, Madadi Vineeth Reddy wrote:
> On 18/11/25 00:25, K Prateek Nayak wrote:
>> commit 1a6151017ee5 ("sched: psi: pass enqueue/dequeue flags to psi
>> callbacks directly") modified the psi_enqueue() and psi_dequeue()
>> functions to take the complete enqueue/dequeue flags but left the stubs
>> for !CONFIG_PSI unaltered.
>>
>> Modify the stubs to also accept the flags argument to keep it consistent
>> with CONFIG_PSI.
>>
>> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
>> ---
>>  kernel/sched/stats.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
>> index cbf7206b3f9d..3323d773fec3 100644
>> --- a/kernel/sched/stats.h
>> +++ b/kernel/sched/stats.h
>> @@ -221,8 +221,8 @@ static inline void psi_sched_switch(struct task_struct *prev,
>>  }
>>  
>>  #else /* !CONFIG_PSI: */
>> -static inline void psi_enqueue(struct task_struct *p, bool migrate) {}
>> -static inline void psi_dequeue(struct task_struct *p, bool migrate) {}
>> +static inline void psi_enqueue(struct task_struct *p, int flags) {}
>> +static inline void psi_dequeue(struct task_struct *p, int flags) {}
>>  static inline void psi_ttwu_dequeue(struct task_struct *p) {}
>>  static inline void psi_sched_switch(struct task_struct *prev,
>>  				    struct task_struct *next,
> 
> Right. The commit that updated the function signature did not update the
> !CONFIG_PSI stubs accordingly. This patch corrects that.
> 
> Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>

Thanks for the review.

P.S. John has an alternate fix for the same at
https://lore.kernel.org/lkml/20251118055242.4030849-1-jstultz@google.com/

That considers a blocked donor as a runnable entity from PSI
standpoint.

This series implements the alternate approach of blocking the PSI signals
when the blocked donor is retained on the rq, skipping the block_task()
and it enqueues the PSI signal back when the donor is woken up again.

-- 
Thanks and Regards,
Prateek

Re: [PATCH 1/5] sched/psi: Make psi stubs consistent for !CONFIG_PSI

[Madadi Vineeth Reddy]

Hi Prateek,

On 20/11/25 11:40, K Prateek Nayak wrote:
> Hello Vineeth,
> 
> On 11/20/2025 11:29 AM, Madadi Vineeth Reddy wrote:
>> On 18/11/25 00:25, K Prateek Nayak wrote:
>>> commit 1a6151017ee5 ("sched: psi: pass enqueue/dequeue flags to psi
>>> callbacks directly") modified the psi_enqueue() and psi_dequeue()
>>> functions to take the complete enqueue/dequeue flags but left the stubs
>>> for !CONFIG_PSI unaltered.
>>>
>>> Modify the stubs to also accept the flags argument to keep it consistent
>>> with CONFIG_PSI.
>>>
>>> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
>>> ---
>>>  kernel/sched/stats.h | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h
>>> index cbf7206b3f9d..3323d773fec3 100644
>>> --- a/kernel/sched/stats.h
>>> +++ b/kernel/sched/stats.h
>>> @@ -221,8 +221,8 @@ static inline void psi_sched_switch(struct task_struct *prev,
>>>  }
>>>  
>>>  #else /* !CONFIG_PSI: */
>>> -static inline void psi_enqueue(struct task_struct *p, bool migrate) {}
>>> -static inline void psi_dequeue(struct task_struct *p, bool migrate) {}
>>> +static inline void psi_enqueue(struct task_struct *p, int flags) {}
>>> +static inline void psi_dequeue(struct task_struct *p, int flags) {}
>>>  static inline void psi_ttwu_dequeue(struct task_struct *p) {}
>>>  static inline void psi_sched_switch(struct task_struct *prev,
>>>  				    struct task_struct *next,
>>
>> Right. The commit that updated the function signature did not update the
>> !CONFIG_PSI stubs accordingly. This patch corrects that.
>>
>> Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
> 
> Thanks for the review.
> 
> P.S. John has an alternate fix for the same at
> https://lore.kernel.org/lkml/20251118055242.4030849-1-jstultz@google.com/

Thanks for pointing this out. While going through the discussion I had seen it
in John's tree, but I hadn't realized it was already posted upstream.

I gave the Reviewed-by since the first two cleanup patches still seem valid
and can go in independently of that alternate fix.

Thanks,
Vineeth

> 
> That considers a blocked donor as a runnable entity from PSI
> standpoint.
> 
> This series implements the alternate approach of blocking the PSI signals
> when the blocked donor is retained on the rq, skipping the block_task()
> and it enqueues the PSI signal back when the donor is woken up again.
> 

Re: [PATCH 1/5] sched/psi: Make psi stubs consistent for !CONFIG_PSI

[Johannes Weiner]

On Mon, Nov 17, 2025 at 06:55:46PM +0000, K Prateek Nayak wrote:
> commit 1a6151017ee5 ("sched: psi: pass enqueue/dequeue flags to psi
> callbacks directly") modified the psi_enqueue() and psi_dequeue()
> functions to take the complete enqueue/dequeue flags but left the stubs
> for !CONFIG_PSI unaltered.
> 
> Modify the stubs to also accept the flags argument to keep it consistent
> with CONFIG_PSI.
> 
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Re: [PATCH 2/5] sched/psi: Prepend "0x" to format specifiers when printing PSI flags

[Johannes Weiner]

On Mon, Nov 17, 2025 at 06:55:47PM +0000, K Prateek Nayak wrote:
> It is not immediately clear that the PSI flags, the set, and the clear
> bits printed in PSI warnings are hexadecimal values. Prepend "0x" to
> format specifiers to make it clear.
> 
> Since "kernel/sched" uses "0x%x" as opposed to "%#x" when printing
> hexadecimal values, the same was followed to keep consistency.
> 
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>