From: Lu Wang <wanglu.priv@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Lu Wang <wanglu.priv@gmail.com>,
mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, yu.c.chen@intel.com,
tim.c.chen@linux.intel.com, chen.yu@linux.dev,
kprateek.nayak@amd.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] sched/cache: honor migrate_llc_task semantics in active load balance
Date: Mon, 24 Aug 2026 10:33:23 +0800 [thread overview]
Message-ID: <20260824023324.3663800-1-wanglu.priv@gmail.com> (raw)
In-Reply-To: <20260813045241.3039862-1-wanglu.priv@gmail.com>
> 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
prev parent reply other threads:[~2026-08-24 2:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 4:52 [PATCH v3] sched/cache: honor migrate_llc_task semantics in active load balance Lu Wang
2026-08-24 2:33 ` Lu Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260824023324.3663800-1-wanglu.priv@gmail.com \
--to=wanglu.priv@gmail.com \
--cc=bsegall@google.com \
--cc=chen.yu@linux.dev \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.