Re: [PATCH 08/18] sched: Introduce WF_ON_RQ wake flag

From: John Stultz

Date: Tue Sep 15 2026 - 17:16:27 EST


On Tue, Sep 15, 2026 at 1:55 PM Andrea Righi <arighi@xxxxxxxxxx> wrote:
> On Thu, Sep 10, 2026 at 12:45:28PM +0200, Peter Zijlstra wrote:
> > On Mon, Aug 31, 2026 at 03:42:18PM +0200, Andrea Righi wrote:
> > > ttwu_runnable() handles wakeups for tasks which are already on the
> > > runqueue, but scheduling classes cannot distinguish that path from a
> > > full wakeup activation in wakeup_preempt().
> > >
> > > Pass WF_ON_RQ to wakeup_preempt() from ttwu_runnable() so scheduling
> > > classes can handle already-runnable wakeups separately.
> > >
> > > This is a preparatory change to support proxy execution with sched_ext.
> > > No functional change.
> > >
> > > Signed-off-by: Andrea Righi <arighi@xxxxxxxxxx>
> > > ---
> > > kernel/sched/core.c | 2 +-
> > > kernel/sched/sched.h | 1 +
> > > 2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > index d578dd635f2eb..f142ab455b797 100644
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -3908,7 +3908,7 @@ static int ttwu_runnable(struct task_struct *p, int wake_flags)
> > > * When on_rq && !on_cpu the task is preempted, see if
> > > * it should preempt the task that is current now.
> > > */
> > > - wakeup_preempt(rq, p, wake_flags);
> > > + wakeup_preempt(rq, p, wake_flags | WF_ON_RQ);
> > > }
> > > ttwu_do_wakeup(p);
> > > return 1;
> > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > > index 56ac104f1f825..f30d122909e7b 100644
> > > --- a/kernel/sched/sched.h
> > > +++ b/kernel/sched/sched.h
> > > @@ -2538,6 +2538,7 @@ static inline int task_on_rq_migrating(struct task_struct *p)
> > > #define WF_MIGRATED 0x20 /* Internal use, task got migrated */
> > > #define WF_CURRENT_CPU 0x40 /* Prefer to move the wakee to the current CPU. */
> > > #define WF_RQ_SELECTED 0x80 /* ->select_task_rq() was called */
> > > +#define WF_ON_RQ 0x100 /* Wakeup of an already runnable task */
> >
> > I are confused again... help?
> >
> > wakeup_preempt() can only ever be called for tasks that are on the
> > runqueue. That is more or less the point of wakeup-preemption.
> >
> > Even the already-runnable distinction would mean things like
> > move_queued_task() should also have this. The task is new to this
> > runqueue, but was definitely already runnable before.
> >
> > What actual distinction are you needing?
>
> Hm... yeah, WF_ON_RQ describes the wrong distinction.
>
> What sched_ext actually needs to know is: did this wakeup use ttwu_runnable(),
> changing the task back to TASK_RUNNING without calling activate_task() /
> enqueue_task()?
>
> We need the distinction because a retained proxy donor remains on the runqueue
> while blocked. When it wakes, ttwu_runnable() can clear its blocked state
> without calling enqueue_task_scx() again.
>
> sched_ext must therefore request a reschedule so the newly unblocked task
> is reconsidered for dispatch. We don't want this extra reschedule for a normal
> wakeup because that path already called enqueue_task_scx() and performed the
> required sched_ext bookkeeping.

Would it be sufficient to just drop the if (task_cpu(p) ==
p->wake_cpu) shortcut in proxy_needs_return()?
(or conditionalize it on the sched_class?)

thanks
-john