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

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Nov 12, 2026 at 12:29:14PM +0100, Vincent Guittot wrote:
> On Thu, 12 Nov 2026 at 10:49, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Thu, Nov 12, 2026 at 08:01:17AM +0100, Vincent Guittot wrote:
> >
> > > 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?
> >
> > Well, effectively cfs_tasks *is* the pushable list. The below patch
> > makes no effective difference, and can be argued to be an optimization.
> > Currently every consumer of cfs_tasks goes through can_migrate_task()
> > and every task that has nr_cpus_allowed == 1, will fail that function.
> >
> > The thing seems to be that you want additional constraints on your list;
> > like dropping tasks after one push attempt. The other classes don't do
> > that, they do the same thing cfs_tasks does and keep all runnable tasks
> > that can migrate on the list.
> >
> > I'm not against adding another list per-se, I'm just struggling to
> > understand your extra semantics, because its not _just_ another pushable
> > list, it has some extra flavour.
> 
> The main case is to periodically look for another CPU when a task is
> put back in the runnable list. I also have other cases like patch 20
> where several short tasks end up selecting the same CPU or when the
> short task finally can run 1st and should look for another CPU.
> Because anything can happen between wakeup preempt and pick_task_fair
> I don't know if the 1st item is the one that might to be pushed or how
> much requested it

I've yet to go read 20; but can we cure all this by making cfs_tasks a
RB-tree and imposing some convenient order on it?

Perhaps sort on {se->slice,se->exec_start}, that way the shortest slice
that hasn't ran for the longest is first. So when all slices are equal
length, it is similar to what we have now, but when there are multiple
slice lengths, the shorter ones are preferred.

That is; instead of trimming the length of the 'list', make sure the
right task ends up at the right place.

Another option is to so an augmented list, normally sorted on
se->exec_start, but augmented on se->slice, such that normally you pick
in longest-not-ran order, but can also pick in shortest slice order.