Message-ID: <CANDhNCoe21MYZUmOoa7G0ecU9SJKTFtEp-LjOJXAsCj-ZpQb6Q@mail.gmail.com>
Date: Fri, 5 Dec 2025 20:49:34 -0800
From: John Stultz <jstultz@...gle.com>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Qais Yousef <qyousef@...alina.io>, 
	Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, 
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Valentin Schneider <vschneid@...hat.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, 
	Zimuzo Ezeozue <zezeozue@...gle.com>, Mel Gorman <mgorman@...e.de>, Will Deacon <will@...nel.org>, 
	Waiman Long <longman@...hat.com>, Boqun Feng <boqun.feng@...il.com>, 
	"Paul E. McKenney" <paulmck@...nel.org>, Metin Kaya <Metin.Kaya@....com>, 
	Xuewen Yan <xuewen.yan94@...il.com>, K Prateek Nayak <kprateek.nayak@....com>, 
	Thomas Gleixner <tglx@...utronix.de>, Daniel Lezcano <daniel.lezcano@...aro.org>, 
	Tejun Heo <tj@...nel.org>, David Vernet <void@...ifault.com>, Andrea Righi <arighi@...dia.com>, 
	Changwoo Min <changwoo@...lia.com>, sched-ext@...ts.linux.dev, kernel-team@...roid.com
Subject: Re: [RFC][PATCH] sched/ext: Split curr|donor references properly

On Fri, Dec 5, 2025 at 6:47 PM Joel Fernandes <joelagnelf@...dia.com> wrote:
> On Sat, Dec 06, 2025 at 12:14:45AM +0000, John Stultz wrote:
> > With proxy-exec, we want to do the accounting against the donor
> > most of the time. Without proxy-exec, there should be no
> > difference as the rq->donor and rq->curr are the same.
> >
> > So rework the logic to reference the rq->donor where appropriate.
> >
> > Also add donor info to scx_dump_state()
> >
> > Since CONFIG_SCHED_PROXY_EXEC currently depends on
> > !CONFIG_SCHED_CLASS_EXT, this should have no effect
> > (other then the extra donor output in scx_dump_state),
> > but this is one step needed to eventually remove that
> > constraint for proxy-exec.
> >
> > Just wanted to send this out for early review prior to LPC.
> >
> > Feedback or thoughts would be greatly appreciated!
>
> Hi John,
>
> I'm wondering if this will work well for BPF tasks because my understanding
> is that some scheduler BPF programs also monitor runtime statistics. If they are unaware of proxy execution, how will it work?

Good question! Be sure to come to my LPC talk on this next week! :)
https://lpc.events/event/19/contributions/2032/

> I don't see any code in the patch that passes the donor information to the
> BPF ops, for instance. I would really like the SCX folks to chime in before
> we can move this patch forward. Thanks for marking it as an RFC.

Oh yes, this RFC is intended to just be something to open initial
discussion for the session next week. I'm very much hoping to get
further thoughts on it, in person, next week.

> We need to get a handle on how a scheduler BPF program will pass information
> about the donor to the currently executing task. If we can make this happen
> transparently, that's ideal. Otherwise, we may have to pass both the donor
> task and the currently executing task to the BPF ops.

So, one thing about proxy-exec is the class schedulers are pretty much
are to keep their existing behavior. Its just the core scheduler may
not actually run what they pick.

That's ok, as the task they pick becomes the rq->donor that we want to
use for pretty much all the scheduling accounting (the exception being
the cputime accounting necessary for cputimers on the running task to
behave sanely as well as top output - as you have helped identify
earlier).  So this patch is just shifting the class scheduler to
utilize the donor pointer instead of curr, so we are consistent in the
proxy case.

As for the concern about communicating the split context (rq->donor vs
rq->curr) to the bpf program, to my understanding, the DSQ abstraction
seems to make that unnecessary. It provides a general enough interface
for the bpf logic, that it seems we only have to worry about the split
context on the the sched/ext.c logic side as it processes the DSQ.
That said, I'm no sched_ext expert, so I'm hoping at LPC we can find
any edge cases that do need to be dealt with.

Now, some of the sched/ext.c logic does seem to want to know if idle
is running, so that's the only case where I've left rq->curr. But I
believe the switching to donor that this patch does, should be ok,
since without proxy-exec rq->donor==rq->cur.

Elsewhere there are outstanding issues, as  proxy-exec needing to
briefly schedule idle (see proxy_resched_idle()), in order to get the
current task off the cpu, and this seems to cause confusion around
SCX_ENQ_LAST logic (since proxy-exec may briefly switch to idle even
if there's a runnable task).  So these items do need to get resolved
before we remove the Kconfig exclusivity between proxy-exec and
sched_ext. But again, I'm looking forward to next week to try to hear
what folks think the best approach will be.

Thanks again for the thought here! Always appreciate your feedback!
-john

Powered by blists - more mailing lists