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

[Lu Wang]

> CAS introduced the migrate_llc_task migration type to direct tasks
> toward their preferred LLC, but its semantics can be lost when passive
> load balance falls back to active load balance. This may allow ALB to
> select a candidate whose preferred LLC does not match the destination,
> moving it away from its preferred LLC.
>
> Example scenario:
>
> src_rq has two runnable tasks, p1 and p2. p1 prefers dst_rq (dst_llc),
> while p2 prefers src_rq (src_llc). In this case, migrate_llc_task is
> set because src_rq has at least one task, p1, that wants to migrate to
> dst_rq. In ALB, can_migrate_task() finds p2 and returns true for it,
> thus moving p2 out of its preferred LLC.
>
> Solution:
>
> The CPU stopper in ALB constructs a fresh lb_env that does not inherit
> migration_type from the passive load-balance pass. Two approaches are
> possible:
>
> (a) Add a new member to struct rq so ALB can inherit migrate_llc_task
>     from the passive LB that triggered it.
>
> (b) Define a new flag LBF_ACTIVE_LB_LLC and select the stopper callback
>     at kick time to preserve the migration semantics across the
>     asynchronous boundary.
>
> We choose (b) because it avoids passing migration_type through the
> stopper, which would affect the meaning of migration_type for
> delayed-dequeue tasks.

Hi Peter,

Just a gentle ping on this patch.

The v3 received Reviewed-by tags from Tim Chen and Chen Yu.
Would you be happy to take this patch, or are any further changes needed?

Thanks,
Lu