mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: John Stultz <jstultz@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Haiyue Wang <haiyuewa@163.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Joel Fernandes <joelagnelf@nvidia.com>,
	Qais Yousef <qyousef@layalina.io>, Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Valentin Schneider <vschneid@redhat.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>,
	Zimuzo Ezeozue <zezeozue@google.com>,
	Mel Gorman <mgorman@suse.de>, Will Deacon <will@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Metin Kaya <Metin.Kaya@arm.com>,
	Xuewen Yan <xuewen.yan94@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Suleiman Souhlal <suleiman@google.com>,
	kuyo chang <kuyo.chang@mediatek.com>, hupu <hupu.gm@gmail.com>,
	kernel-team@android.com
Subject: Re: [PATCH v3] sched: Fix psi_dequeue for Proxy Execution
Date: Fri, 5 Dec 2025 16:24:32 +0100	[thread overview]
Message-ID: <20251205152432.GC2528459@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20251205012721.756394-1-jstultz@google.com>

On Fri, Dec 05, 2025 at 01:27:09AM +0000, John Stultz wrote:
> Currently, if the sleep flag is set, psi_dequeue() doesn't
> change any of the psi_flags.
> 
> This is because psi_task_switch() will clear TSK_ONCPU as well
> as other potential flags (TSK_RUNNING), and the assumption is
> that a voluntary sleep always consists of a task being dequeued
> followed shortly there after with a psi_sched_switch() call.
> 
> Proxy Execution changes this expectation, as mutex-blocked tasks
> that would normally sleep stay on the runqueue. But in the case
> where the mutex-owning task goes to sleep, or the owner is on a
> remote cpu, we will then deactivate the blocked task shortly
> after.
> 
> In that situation, the mutex-blocked task will have had its
> TSK_ONCPU cleared when it was switched off the cpu, but it will
> stay TSK_RUNNING. Then if we later dequeue it (as currently done
> if we hit a case find_proxy_task() can't yet handle, such as the
> case of the owner being on another rq or a sleeping owner)
> psi_dequeue() won't change any state (leaving it TSK_RUNNING),
> as it incorrectly expects a psi_task_switch() call to
> immediately follow.
> 
> Later on when the task get woken/re-enqueued, and psi_flags are
> set for TSK_RUNNING, we hit an error as the task is already
> TSK_RUNNING:
>   psi: inconsistent task state! task=188:kworker/28:0 cpu=28 psi_flags=4 clear=0 set=4
> 
> To resolve this, extend the logic in psi_dequeue() so that
> if the sleep flag is set, we also check if psi_flags have
> TSK_ONCPU set (meaning the psi_task_switch is imminent) before
> we do the shortcut return.
> 
> If TSK_ONCPU is not set, that means we've already switched away,
> and this psi_dequeue call needs to clear the flags.
> 
> Fixes: be41bde4c3a8 ("sched: Add an initial sketch of the find_proxy_task() function")
> Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Closes: https://lore.kernel.org/lkml/20251117185550.365156-1-kprateek.nayak@amd.com/
> Signed-off-by: John Stultz <jstultz@google.com>
> Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
> Tested-by: Haiyue Wang <haiyuewa@163.com>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Stuck this on my post rc1 pile to look at.

  reply	other threads:[~2025-12-05 15:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-05  1:27 John Stultz
2025-12-05 15:24 ` Peter Zijlstra [this message]
2025-12-06  9:22 ` [tip: sched/urgent] sched/core: Fix psi_dequeue() " tip-bot2 for John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251205152432.GC2528459@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Metin.Kaya@arm.com \
    --cc=boqun.feng@gmail.com \
    --cc=bsegall@google.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=haiyuewa@163.com \
    --cc=hannes@cmpxchg.org \
    --cc=hupu.gm@gmail.com \
    --cc=joelagnelf@nvidia.com \
    --cc=jstultz@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@android.com \
    --cc=kprateek.nayak@amd.com \
    --cc=kuyo.chang@mediatek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=qyousef@layalina.io \
    --cc=rostedt@goodmis.org \
    --cc=suleiman@google.com \
    --cc=surenb@google.com \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=will@kernel.org \
    --cc=xuewen.yan94@gmail.com \
    --cc=zezeozue@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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®