From: Peter Zijlstra <peterz@infradead.org>
To: Andrea Righi <arighi@nvidia.com>
Cc: Tejun Heo <tj@kernel.org>, David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
John Stultz <jstultz@google.com>, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
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>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Christian Loehle <christian.loehle@arm.com>,
David Dai <david.dai@linux.dev>, Koba Ko <kobak@nvidia.com>,
Aiqun Yu <aiqun.yu@oss.qualcomm.com>,
Shuah Khan <shuah@kernel.org>,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 05/16] sched: Add sched_ext hooks for proxy execution
Date: Thu, 24 Sep 2026 09:51:07 +0200 [thread overview]
Message-ID: <20260924075107.GC4121339@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260922165445.943315-6-arighi@nvidia.com>
On Tue, Sep 22, 2026 at 06:51:44PM +0200, Andrea Righi wrote:
> Proxy execution splits the scheduling context (the donor) from the
> execution context (the lock owner). sched_ext needs to observe that
> split at three points in __schedule():
>
> - whether a blocked EXT task can be retained on the runqueue as a
> donor,
> - when a donor's scheduling context starts driving a lock owner,
> - after proxy resolution, when deferred reenqueue work that was blocked
> by an active proxy relationship can be retried.
>
> Introduce scx_allow_proxy_exec(), scx_proxy_donor_start() and
> scx_proxy_reenqueue_retry(), and add their call sites in __schedule().
> The implementations are empty here and are filled in by the sched_ext
> changes that follow, so that all the sched core changes needed by proxy
> execution stay together in the preparatory patches.
>
> SCHED_PROXY_EXEC still depends on !SCHED_CLASS_EXT, so the new hooks are
> inert: they are compiled out with CONFIG_SCHED_CLASS_EXT=n and
> unreachable otherwise.
>
> This is a preparatory change to support proxy execution with sched_ext.
> No functional change.
>
> Signed-off-by: Andrea Righi <arighi@nvidia.com>
> ---
> @@ -7243,6 +7242,7 @@ static void __sched notrace __schedule(int sched_mode)
> }
> if (next == rq->idle) {
> zap_balance_callbacks(rq);
> + scx_proxy_reenqueue_retry(rq, next);
> goto keep_resched;
> }
> }
> @@ -7263,6 +7263,8 @@ static void __sched notrace __schedule(int sched_mode)
> donor->sched_class->put_prev_task(rq, donor, donor);
> donor->sched_class->set_next_task(rq, donor, true);
> }
> + scx_proxy_donor_start(rq);
> + scx_proxy_reenqueue_retry(rq, next);
> } else {
> rq_set_donor(rq, next);
> }
> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index f60894dbf0623..aaa6ee66917e8 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
> @@ -1110,6 +1115,10 @@ static void schedule_deferred_locked(struct rq *rq)
> schedule_deferred(rq);
> }
>
> +void scx_proxy_reenqueue_retry(struct rq *rq)
> +{
> +}
Doesn't match its prototype, also, I'm a little confused about the next
argument in the next == rq->idle case.
Hmm, you seem to be using the argument like:
bool proxy = next != rq->donor;
And I suppose that works. But that seems to be about the tick, not
putting current back on a dsq.
> diff --git a/kernel/sched/ext/ext.h b/kernel/sched/ext/ext.h
> index 0012f708a5504..cca3f7c97b788 100644
> --- a/kernel/sched/ext/ext.h
> +++ b/kernel/sched/ext/ext.h
> @@ -20,6 +20,9 @@ void scx_rq_deactivate(struct rq *rq);
> int scx_check_setscheduler(struct task_struct *p, int policy);
> bool task_should_scx(int policy);
> bool scx_allow_ttwu_queue(const struct task_struct *p);
> +bool scx_allow_proxy_exec(const struct task_struct *p);
> +void scx_proxy_donor_start(struct rq *rq);
> +void scx_proxy_reenqueue_retry(struct rq *rq, struct task_struct *next);
> void init_sched_ext_class(void);
> void __scx_update_idle(struct rq *rq, bool idle, bool do_notify);
>
next prev parent reply other threads:[~2026-09-24 7:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 16:51 [PATCHSET v14 sched_ext/for-7.4] sched: Make proxy execution compatible with sched_ext Andrea Righi
2026-09-22 16:51 ` [PATCH 01/16] sched/core: Drop mutex locks before proxy rescheduling Andrea Righi
2026-09-22 16:51 ` [PATCH 02/16] sched/core: Dequeue waking proxy donors before reset Andrea Righi
2026-09-22 16:51 ` [PATCH 03/16] sched/core: Mark wakeups completed through ttwu_runnable() Andrea Righi
2026-09-22 16:51 ` [PATCH 04/16] sched: Add helper to block retained proxy donors Andrea Righi
2026-09-22 16:51 ` [PATCH 05/16] sched: Add sched_ext hooks for proxy execution Andrea Righi
2026-09-24 7:51 ` Peter Zijlstra [this message]
2026-09-22 16:51 ` [PATCH 06/16] sched_ext: Block proxy donors before taking control Andrea Righi
2026-09-22 16:51 ` [PATCH 07/16] sched_ext: Fix ops.running/stopping() pairing for proxy-exec donors Andrea Righi
2026-09-22 16:51 ` [PATCH 08/16] sched_ext: Move reject DSQ draining into core Andrea Righi
2026-09-22 16:51 ` [PATCH 09/16] sched_ext: Generalize the reject DSQ reenqueue path Andrea Righi
2026-09-22 16:51 ` [PATCH 10/16] sched_ext: Handle proxy-exec races in remote DSQ transfers Andrea Righi
2026-09-22 16:51 ` [PATCH 11/16] sched_ext: Split curr|donor references properly Andrea Righi
2026-09-22 16:51 ` [PATCH 12/16] sched_ext: Track proxy execution for NOHZ_FULL Andrea Righi
2026-09-22 16:51 ` [PATCH 13/16] sched_ext: Delegate proxy donor admission to BPF schedulers Andrea Righi
2026-09-22 16:51 ` [PATCH 14/16] sched_ext: Add selftest for blocked donor admission Andrea Righi
2026-09-22 16:51 ` [PATCH 15/16] sched_ext: scx_qmap: Add proxy execution support Andrea Righi
2026-09-22 16:51 ` [PATCH 16/16] sched: Allow enabling proxy exec with sched_ext Andrea Righi
2026-09-24 7:52 ` [PATCHSET v14 sched_ext/for-7.4] sched: Make proxy execution compatible " Peter Zijlstra
2026-09-24 7:59 ` Peter Zijlstra
2026-09-24 8:10 ` K Prateek Nayak
2026-09-24 9:09 ` Peter Zijlstra
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=20260924075107.GC4121339@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aiqun.yu@oss.qualcomm.com \
--cc=arighi@nvidia.com \
--cc=bsegall@google.com \
--cc=changwoo@igalia.com \
--cc=christian.loehle@arm.com \
--cc=david.dai@linux.dev \
--cc=dietmar.eggemann@arm.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=kobak@nvidia.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sched-ext@lists.linux.dev \
--cc=shuah@kernel.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.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
all inboxes | Powered by JetHome®