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

[Andrea Righi]

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.

Thanks,
-Andrea