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

[Chen Yu <yu.c.chen@intel.com>]

On Mon, Oct 12, 2026 at 11:18:04AM +0200, Vincent Guittot wrote:
> On Sat, 10 Oct 2026 at 17:55, Chen Yu <yu.c.chen@intel.com> 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@intel.com> 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
>

Do you mean the check in fair_check_pushable_task() should be lightweight
and let select_task_rq_fair() make the decision as to which CPU the task
should be migrated to, because the former does not hold pi_lock and thus
should be best-effort? OK, let me adjust the code.

thanks,
Chenyu

> Vincent
> 
> >
> > thanks,
> > Chenyu