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

[Peter Zijlstra]

On Mon, Nov 09, 2026 at 05:07:31PM +0100, Vincent Guittot wrote:
> 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

There is still a worst case where a lot of tasks get woken, they all get
enqueued and then they all get on this list and you need to iterate them
all.

If you want to bound this thing, you might as well do like
detach_one_task(). Only ever consider the first task from the end that
is suitable.