From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Peter Zijlstra <peterz@infradead.org>, John Stultz <jstultz@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
zhidao su <suzhidao@xiaomi.com>, 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>,
Johannes Weiner <hannes@cmpxchg.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Joel Fernandes <joelagnelf@nvidia.com>,
Qais Yousef <qyousef@layalina.io>,
Xuewen Yan <xuewen.yan94@gmail.com>,
Suleiman Souhlal <suleiman@google.com>,
kuyo chang <kuyo.chang@mediatek.com>, hupu <hupu.gm@gmail.com>,
<soolaugust@gmail.com>, <kernel-team@android.com>
Subject: Re: [RFC][PATCH 2/2] sched: proxy-exec: Add allow/prevent_migration hooks in the sched classes for proxy_tag_curr
Date: Thu, 5 Mar 2026 09:32:05 +0530 [thread overview]
Message-ID: <d5ac8ea9-e9e3-4888-b9a2-c316d6209b70@amd.com> (raw)
In-Reply-To: <20260304131828.GR606826@noisy.programming.kicks-ass.net>
Hello Peter,
On 3/4/2026 6:48 PM, Peter Zijlstra wrote:
> +static inline void set_proxy_task(struct task_struct *p)
> {
> - if (!sched_proxy_exec())
> - return;
> - /*
> - * pick_next_task() calls set_next_task() on the chosen task
> - * at some point, which ensures it is not push/pullable.
> - * However, the chosen/donor task *and* the mutex owner form an
> - * atomic pair wrt push/pull.
> - *
> - * Make sure owner we run is not pushable. Unfortunately we can
> - * only deal with that by means of a dequeue/enqueue cycle. :-/
> - */
> - dequeue_task(rq, owner, DEQUEUE_NOCLOCK | DEQUEUE_SAVE);
> - enqueue_task(rq, owner, ENQUEUE_NOCLOCK | ENQUEUE_RESTORE);
> + WARN_ON_ONCE(p->migration_flags & MDF_PROXY);
> + p->migration_flags |= MDF_PROXY;
> + p->migration_disabled++;
> +}
> +
> +static inline void put_proxy_task(struct task_struct *p)
> +{
> + WARN_ON_ONCE(!(p->migration_flags & MDF_PROXY));
> + p->migration_flags &= ~MDF_PROXY;
> + p->migration_disabled--;
Note: I'm not too familiar with the set_affinity bits so my
understanding might be all wrong but ...
Doesn't the set_affinity bits have a completion based wait for tasks
that are migration disabled? If we have a case like:
P0 P1
== ==
migrate_disable()
p->migration_disabled++; /* 1 */
...
mutex_lock()
...
/* preempted */
/* proxied */
set_proxy_task(P0)
p->migration_disabled++; /* 2 */
...
/* Continues running */
set_cpus_allowed_ptr(P0)
/* Task CPU not in the new mask. */
affine_move_task()
/*
* blocks as per the comment
* above affine_move_task().
*/
migrate_enable()
if (p->migration_disabled > 1)
p->migration_disabled--; /* 1 */
return;
...
mutex_unlock();
/* Goes into schedule. */
put_proxy_task(P0)
p->migration_disabled--; /* 0 */
/* !!! Who does the migration + wakeup? !!! */
Isn't it up to the last migrate_enable() (or in this case,
put_proxy_task()) to schedule in the stopper and push the prev to
another CPU? Or is it handled in some other way?
> }
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2026-03-05 4:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 6:38 [RFC][PATCH 1/2] sched: proxy-exec: Fix tasks being left unpushable from proxy_tag_curr() John Stultz
2026-03-04 6:38 ` [RFC][PATCH 2/2] sched: proxy-exec: Add allow/prevent_migration hooks in the sched classes for proxy_tag_curr John Stultz
2026-03-04 13:18 ` Peter Zijlstra
2026-03-05 4:02 ` K Prateek Nayak [this message]
2026-03-05 14:46 ` Peter Zijlstra
2026-03-07 1:36 ` John Stultz
2026-03-07 7:39 ` [RFC][PATCH] sched: Make class_schedulers avoid pushing current, and get rid of proxy_tag_curr() John Stultz
2026-03-07 9:40 ` Peter Zijlstra
2026-03-05 7:31 ` [RFC][PATCH 2/2] sched: proxy-exec: Add allow/prevent_migration hooks in the sched classes for proxy_tag_curr 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=d5ac8ea9-e9e3-4888-b9a2-c316d6209b70@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.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=kuyo.chang@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=soolaugust@gmail.com \
--cc=suleiman@google.com \
--cc=suzhidao@xiaomi.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xuewen.yan94@gmail.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
Powered by JetHome