Re: [PATCH] sched/core: Preserve wake flags across queued wakeups

[K Prateek Nayak]

Hello Shubhang,

On 7/11/2026 10:47 AM, Shubhang Kaushik (Ampere) wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 373bcc0598d10b4256a11f8c8373ece78fa5e0e5..5d55cdf696c13ed1c95869a1b6fb4dc1485727dc 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1003,12 +1003,12 @@ struct task_struct {
>          * schedule()                     if (p->on_rq && ..) // false
>          *   smp_mb__after_spinlock();    if (smp_load_acquire(&p->on_cpu) && //true
>          *   deactivate_task()                ttwu_queue_wakelist())
> -        *     p->on_rq = 0;                    p->sched_remote_wakeup = Y;
> +        *     p->on_rq = 0;                    p->sched_remote_wakeup_flags = Y;
>          *
>          * guarantees all stores of 'current' are visible before
> -        * ->sched_remote_wakeup gets used, so it can be in this word.
> +        * ->sched_remote_wakeup_flags gets used, so it can be in this word.
>          */
> -       unsigned                        sched_remote_wakeup:1;
> +       unsigned                        sched_remote_wakeup_flags:8;

If we are keeping a byte for it, we can just make it a u8 just after
the "personality" variable.

The reason to keep it at a byte boundary from the rq_lock serialized
stuff was to prevent clobbering them but that would be moot now since a
byte sized writes is always atomic across all architectures afaik.
(https://lore.kernel.org/lkml/20201116142005.GE3121392@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/)


>  #ifdef CONFIG_RT_MUTEXES
>         unsigned                        sched_rt_mutex:1;
>  #endif
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 96226707c2f6135341aa779b8262f113e103d8ad..0d2918b66be277ec09109022bf3ede4b9ec8220c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3902,13 +3902,17 @@ void sched_ttwu_pending(void *arg)
>         update_rq_clock(rq);
> 
>         llist_for_each_entry_safe(p, t, llist, wake_entry.llist) {
> +               int wake_flags;
> +
>                 if (WARN_ON_ONCE(p->on_cpu))
>                         smp_cond_load_acquire(&p->on_cpu, !VAL);
> 
>                 if (WARN_ON_ONCE(task_cpu(p) != cpu_of(rq)))
>                         set_task_cpu(p, cpu_of(rq));
> 
> -               ttwu_do_activate(rq, p, p->sched_remote_wakeup ? WF_MIGRATED : 0, &rf);
> +               wake_flags = p->sched_remote_wakeup_flags;
> +               p->sched_remote_wakeup_flags = 0;

No need to reset it. This path is only used for wakeups and next remote
wakeup would set these flags correctly before putting the task on the
list.

> +               ttwu_do_activate(rq, p, wake_flags, &rf);

On aside note: Only preempt_sync() in wakeup_preempt_fair() cares for
this but if the ttwu manages to find an idle CPU, it would preempt the
idle tasks anyways and if there are no idle CPUs and WF_SYNC works, it
will never use the sched_ttwu_pending() path since it is a wakeup on
the local CPU.

So, the question is, are these flags even relevant with the remote
enqueue path?

>         }
> 
>         /*
> @@ -3951,7 +3955,8 @@ static void __ttwu_queue_wakelist(struct task_struct *p, int cpu, int wake_flags
>  {
>         struct rq *rq = cpu_rq(cpu);
> 
> -       p->sched_remote_wakeup = !!(wake_flags & WF_MIGRATED);
> +       p->sched_remote_wakeup_flags = wake_flags &
> +               (WF_TTWU | WF_SYNC | WF_MIGRATED | WF_RQ_SELECTED);

You can define a WF_MASK next to all the WF_* flags definition and
use it here. It is slightly easier on the eyes ;-)

> 
>         WRITE_ONCE(rq->ttwu_pending, 1);
>  #ifdef CONFIG_SMP
> 
-- 
Thanks and Regards,
Prateek