Re: [PATCH 08/20 v3] sched/fair: Add push task mechanism for fair

[Vincent Guittot]

On Mon, 9 Nov 2026 at 15:43, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Fri, Nov 06, 2026 at 04:19:35PM +0100, Vincent Guittot wrote:
> > +static struct task_struct *pick_next_pushable_fair_task(struct rq *rq)
> > +{
> > +     struct task_struct *p;
> > +
> > +     if (!has_pushable_tasks(rq))
> > +             return NULL;
> > +
> > +     p = plist_first_entry(&rq->cfs.pushable_tasks,
> > +                           struct task_struct, pushable_tasks);
> > +
> > +     WARN_ON_ONCE(rq->cpu != task_cpu(p));
> > +     WARN_ON_ONCE(task_current(rq, p));
> > +     WARN_ON_ONCE(p->nr_cpus_allowed <= 1);
> > +     WARN_ON_ONCE(!task_on_rq_queued(p));
> > +
> > +     /*
> > +      * Remove task from the pushable list as we try only once after that
> > +      * the task has been put back in enqueued list.
> > +      */
> > +     plist_del(&p->pushable_tasks, &rq->cfs.pushable_tasks);
> > +
> > +     return p;
> > +}
>
> This means a task will only be pushed once? After which it needs to be
> re-enqueued on the runqueue?

Yes, my goal is to keep the list small to avoid ending up with many
tasks to push. So I only check if prev could be pushed somewhere else

>
> So if it was found during migrate_disable(), its thereafter stuck? --
> this seems a little weird.

If a task is migrate disabled while we are about to look for a
possibly better CPU, it will have to wait until after the next time it
becomes current. This is a simple way to pace the number of tasks to
push in one callback