Re: [PATCH 07/18] sched/fair: Add push task mechanism for fair

[Vincent Guittot]

On Sat, 10 Oct 2026 at 17:55, Chen Yu <yu.c.chen@xxxxxxxxx> wrote:
>
> On Fri, Oct 09, 2026 at 04:31:40PM +0200, Vincent Guittot wrote:
> > On Wed, 7 Oct 2026 at 04:59, Chen Yu <yu.c.chen@xxxxxxxxx> wrote:
>
> [ ... ]
>
> > > @@ -10414,6 +10441,15 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int select_flags)
> > >         if (select_flags & WF_TTWU)
> > >                 want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
> > >
> > > +       /*
> > > +        * Only a push triggered by cache aware scheduling will push the
> > > +        * task towards its preferred LLC. Pushes for other reasons, like short
> > > +        * slice task, uses the default push strategy.
> > > +        */
> > > +       push_cpu = -1;
> > > +       if (select_flags & WF_RQ_PUSH)
> > > +               push_cpu = check_pushable_cache_task(prev_cpu, p);
> >
> > Is there any reason that you do'nt want to migrate the task at wakeup too ?
> >
>
> The wakeup path seems to be too fast to aggregate the tasks, so that multiple
> CPUs try to migrate the task to the same LLC without synchronization - a task
> bouncing issue was observed when cache-aware migration was enabled in the wakeup
> path. We can double-check in the latest kernel to see if that is still the case,
> and to see if we can mitigate that.

Yeah, the goal is to use the same select function for all events;
wakeup and push events should be seen as the same event

Also you should separate the check for adding the task in the pushable
list in fair_check_pushable_task from the decision to select pref_cpu
in select_task_rq_fair. The check added in fair_check_pushable_task is
mainly used to decide if it worth going deeper in the decision with
select_task_rq_fair

Vincent

>
> thanks,
> Chenyu