Re: [PATCH v3] sched/cache: honor migrate_llc_task semantics in active load balance
Lu Wang <[email protected]>
| Newsgroups | org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
> 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