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

[Vincent Guittot]

On Wed, 11 Nov 2026 at 10:02, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Mon, Nov 09, 2026 at 05:14:39PM +0100, Vincent Guittot wrote:
> > On Mon, 9 Nov 2026 at 16:54, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> > > Can't we add the 'p->nr_cpus_allowed > 1' condition to rq->cfs_tasks and
> > > use that, rather than adding yet another list? I mean, its used for
> > > migration, so excluding all pinned tasks actually makes sense.
> >
> > rq->cfs_tasks can be quite large (we even take a breath during LB)
> > whereas this list should be 1 task most of the time (except during
> > wakeup)
>
> Like in the other email; detach_one_task() is also just one task :-)

but in some case I want to do more than one like the case described in patch 20

>
> > > Also, I'm still not sure why we need a plist. The rq->cfs_tasks list is
> > > MRU per set_next_task_fair() moving the current task to the front.
> >
> > The plist was only to reuse struct plist_node pushable_tasks; in
> > struct task that is already there for RT
>
> So while plist makes sense for RT, it doesn't make sense for fair or DL.
> Notably for DL we keep pushable tasks in a RB tree.

I can use a rb tree as well my gaol was only to reuse the
pushable_tasks as those pushable list are exclusive

>
> > > So reserve iterating rq->cfs_tasks, skipping blocked and current and
> > > such, should get you much the same over-all.
> >
> > Yes but I was afraid by the overhead of iterating this list which can
> > be very long; We have already seen email about bug with thousands of
> > tasks queued on the rq
>
> Right, so just take one of the tail and stop there.

I don't want to take any random task from the rq but only one that is
meaningful. Why do you think having a dedicated pushable list like rt
and deadline isn't worthwhile?