Re: [PATCH] sched/cache: honor migrate_llc_task semantics in active load balance

Thanks, both.

On Fri, 2026-08-07 at 14:48 +0800, Chen, Yu C wrote:
> On 8/7/2026 1:22 AM, Tim Chen wrote:
> > On Thu, 2026-08-06 at 23:35 +0800, Chen, Yu C wrote:
> > > It looks like this proposal provides fine-grain control on per-task base
> > > migration strategy is promising.
> > >
> > > If we overwrite migration_type for ALB (default is 0, i.e. migrate_load),
> > > then in can_migrate_task() a delayed task might not be migrated in ALB:
> > >
> > > if ((p->se.sched_delayed) && (env->migration_type != migrate_load))
> > > 	return 0;
> > >
> > > So an enhanced approach I'm thinking of is to pass
> > > migrate_llc_task information via env->flags:
> > >
> > > #define LBF_ACTIVE_LB_LLC      0x40
> > >
> > > static int active_load_balance_cpu_stop(void *data)
> > > {
> > > 	return __active_load_balance_cpu_stop(data, 0);
> > > }
> > >
> > > static int active_load_balance_llc_cpu_stop(void *data)
> > > {
> > > 	return __active_load_balance_cpu_stop(data, LBF_ACTIVE_LB_LLC);
> > > }
> >
> > This is a good catch.
> >
> > It may be easier to create a migrate_llc_task_alb type and pass that
> > in migration type.  Then modify the above as
> >
> > if ((p->se.sched_delayed) && env->migration_type != migrate_load
> > 	          && env->migration_type != migrate_llc_task_alb)
> > 	return 0
>
> We still need a channel to carry migrate_llc_task/migrate_llc_task_alb
> into the alb, since the stopper builds a fresh lb_env - hence
> rq->active_balance_type was introduced in Lu Wang's proposal. We can
> reuse the callback slot in active_balance_work instead, pick
> active_load_balance_llc_cpu_stop() at kick time, thus no new rq field
> is needed.

Good catch. I agree that overwriting migration_type in the stopper
changes the existing delayed-dequeue behavior.

Picking the callback at kick time and dropping the rq field looks
like the cleanest version of this so far -- it fixes the
original issue I raised without affecting delayed-dequeue behavior.
I agree with refactoring the patch along this idea and send patchV3.

Lu Wang