From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Vasily Gorbik <gor@linux.ibm.com>, Ingo Molnar <mingo@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
John Stultz <jstultz@google.com>,
Connor O'Brien <connoro@google.com>,
Vineeth Pillai <vineethrp@google.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
<linux-s390@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] sched/core: Don't steal a proxy-exec donor
Date: Mon, 4 May 2026 18:49:05 +0530 [thread overview]
Message-ID: <10282ce9-f4ae-498f-9b57-f4e1e61fffbc@amd.com> (raw)
In-Reply-To: <p01-01.g703486db8203.ttedd70@ub.hpns>
Hello Vasily,
On 5/4/2026 6:01 PM, Vasily Gorbik wrote:
> try_steal_cookie() avoids stealing src->core_pick and src->curr before
> moving a task with the same cookie via move_queued_task_locked().
>
> With proxy-exec, src->donor is the current scheduling context and may
> differ from src->curr. Stealing it migrates a task that the source rq
> still treats as current. For CFS, src cfs_rq->curr is left pointing
> at the stolen entity and the next pick on src hits the WARN_ON_ONCE
> in put_prev_entity().
>
> Commit 7de9d4f94638 ("sched: Start blocked_on chain processing in
> find_proxy_task()") tweaked the fair class logic so that the donor task
> isn't migrated away while running the proxy. Do it similarly for
> try_steal_cookie() and skip src->donor as well.
>
> Fixes: 7de9d4f94638 ("sched: Start blocked_on chain processing in find_proxy_task()")
> Signed-off-by: Vasily Gorbik <gor@linux.ibm.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 b8871449d3c6..3cf5fb70814c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6358,7 +6358,7 @@ static bool try_steal_cookie(int this, int that)
> return false;
>
> do {
> - if (p == src->core_pick || p == src->curr)
> + if (p == src->core_pick || p == src->curr || p == src->donor)
Although this solves the issue of stealing the donor, I'm a bit
skeptical if proxy exec even works with core scheduling at all since
__schedule() can override the decision of core_pick and the CPU
may end up running a task with different core-cookie if it found
the core_pick to be blocked on a mutex :-(
> goto next;
>
> if (!is_cpu_allowed(p, this))
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2026-05-04 13:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 12:31 [PATCH 0/1] sched/core: Don't steal a proxy-exec donor Vasily Gorbik
2026-05-04 12:31 ` [PATCH 1/1] " Vasily Gorbik
2026-05-04 13:19 ` K Prateek Nayak [this message]
2026-05-05 10:03 ` Vasily Gorbik
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=10282ce9-f4ae-498f-9b57-f4e1e61fffbc@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=connoro@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=gor@linux.ibm.com \
--cc=joelagnelf@nvidia.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vineethrp@google.com \
--cc=vschneid@redhat.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