mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Lu Wang <wanglu.priv@gmail.com>, yu.c.chen@intel.com
Cc: peterz@infradead.org, 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, kprateek.nayak@amd.com,
		linux-kernel@vger.kernel.org, chen.yu@linux.dev
Subject: Re: [PATCH] sched/cache: honor migrate_llc_task semantics in active load balance
Date: Mon, 03 Aug 2026 17:10:26 -0700	[thread overview]
Message-ID: <c20b86364a54bf148a0372c3b68628e28bacf0cd.camel@linux.intel.com> (raw)
In-Reply-To: <20260803100227.2585560-1-wanglu.priv@gmail.com>

On Mon, 2026-08-03 at 18:02 +0800, Lu Wang wrote:
> Thanks for the review, Chenyu.
> 
> I got interested in CAS because it strikes a good balance between
> generic CFS load balancing and strict LLC/CPU affinity.
> 
> My understanding is that migrate_llc_task encodes the target
> direction of the balance pass, not just "ALB was triggered by CAS".
> alb_break_llc() only vetoes ALB when every task on src_rq prefers
> staying put (nr_pref_llc_running == cfs.h_nr_runnable); once tasks
> have mixed preferences it lets ALB through without checking which
> one gets picked. active_load_balance_cpu_stop() then walks
> src_rq->cfs_tasks in reverse and takes the first task accepted by
> can_migrate_task() — with multiple tasks on src_rq, that's not
> necessarily the one whose preferred_llc matches the destination.
> 
> My patch threads migration_type through to the stopper and, only
> for migrate_llc_task, rejects a candidate whose preferred_llc
> doesn't match the destination LLC.
> 
> Regarding:
> > this helps the case where the task is the only running one on the
> > src_cpu
> 
> If that single task already prefers the destination LLC, my check
> still returns true, so this case is unaffected. The disagreement is
> really about what happens when it does not prefer the destination.
> That comes down to how we read the semantics of migrate_llc_task:
> 
>   (a) "migrate a task toward the destination LLC selected by
>       calculate_imbalance()", or
>   (b) "this ALB was triggered by CAS's LLC-balance logic, so any
>       generally-eligible task on src_rq may be pushed"

The policy of when to break LLC preference locality whether it is in regular
load balance or in active load balance are both encoded in
can_migrate_llc().  Sometimes when an LLC is overloaded, you may
want to move the task off its preferred LLC.  Moving a task off its
preferred LLC is not always wrong. Looks like you patch
stop that with migrate_llc_task_wrong_dst().  
There is a comment section above can_migrate_llc() to
explain the policy details.

Tim

> 
> If (a), the per-task check is needed.
> 
> Happy to discuss further.

  reply	other threads:[~2026-08-04  0:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-01 12:22 Lu Wang
2026-08-03  4:20 ` Chen, Yu C
2026-08-03 10:02   ` Lu Wang
2026-08-04  0:10     ` Tim Chen [this message]
2026-08-04  8:17       ` Chen, Yu C
2026-08-04 15:07         ` Lu Wang
2026-08-04 19:42           ` Tim Chen
2026-08-05  2:38             ` wanglu15
2026-08-05 16:04               ` Tim Chen
2026-08-05 16:43                 ` Chen, Yu C
2026-08-06 16:21                   ` Tim Chen
2026-08-04  8:30       ` Lu Wang
2026-08-06 15:35 ` Chen, Yu C
2026-08-06 17:22   ` Tim Chen
2026-08-07  6:48     ` Chen, Yu C
2026-08-07  9:58       ` Lu Wang
2026-08-09 10:53 ` [PATCH v2] " Lu Wang
2026-08-10 20:56   ` Tim Chen
  -- strict thread matches above, loose matches on Subject: below --
2026-08-01 12:17 [PATCH] " Lu Wang

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=c20b86364a54bf148a0372c3b68628e28bacf0cd.camel@linux.intel.com \
    --to=tim.c.chen@linux.intel.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=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=wanglu.priv@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome