From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Tim C Chen <tim.c.chen@linux.intel.com>,
Barry Song <baohua@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
ricardo.neri@intel.com, linux-kernel@vger.kernel.org,
Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Subject: [PATCH RESEND 1/4] sched/fair: Always skip fully_busy higher-capacity groups for load balance
Date: Mon, 30 Mar 2026 15:20:35 -0700 [thread overview]
Message-ID: <20260330-rneri-fix-cas-clusters-v1-1-1e465b6fecb2@linux.intel.com> (raw)
In-Reply-To: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@linux.intel.com>
update_sd_pick_busiest() is supposed to avoid picking as busiest a
candidate scheduling group with no more than one task if its per-CPU
capacity is greater than that of the destination CPU.
update_sd_pick_busiest() selects as busiest a group if its type is greater
than has_spare (the type of the busiest group is initialized as has_spare).
As a result, a fully_busy group with higher per-CPU capacity can still
be selected as busiest.
Relocate the existing comparison of capacities to occur before comparing
the types of the candidate and busiest groups.
Remove unnecessary parentheses while here.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
kernel/sched/fair.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e2963efe800..9da5014f8387 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -10372,6 +10372,17 @@ static bool update_sd_pick_busiest(struct lb_env *env,
sds->local_stat.group_type != group_has_spare))
return false;
+ /*
+ * Candidate sg has no more than one task per CPU and has higher
+ * per-CPU capacity. Migrating tasks to less capable CPUs may harm
+ * throughput. Maximize throughput, power/energy consequences are not
+ * considered.
+ */
+ if (env->sd->flags & SD_ASYM_CPUCAPACITY &&
+ sgs->group_type <= group_fully_busy &&
+ capacity_greater(sg->sgc->min_capacity, capacity_of(env->dst_cpu)))
+ return false;
+
if (sgs->group_type > busiest->group_type)
return true;
@@ -10474,17 +10485,6 @@ static bool update_sd_pick_busiest(struct lb_env *env,
break;
}
- /*
- * Candidate sg has no more than one task per CPU and has higher
- * per-CPU capacity. Migrating tasks to less capable CPUs may harm
- * throughput. Maximize throughput, power/energy consequences are not
- * considered.
- */
- if ((env->sd->flags & SD_ASYM_CPUCAPACITY) &&
- (sgs->group_type <= group_fully_busy) &&
- (capacity_greater(sg->sgc->min_capacity, capacity_of(env->dst_cpu))))
- return false;
-
return true;
}
--
2.43.0
next prev parent reply other threads:[~2026-03-30 22:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 22:20 [PATCH RESEND 0/4] sched: Fix cluster scheduling in the presence of asymmetric capacity Ricardo Neri
2026-03-30 22:20 ` Ricardo Neri [this message]
2026-03-30 22:20 ` [PATCH RESEND 2/4] sched/fair: Ignore misfit load if the destination CPU cannot help Ricardo Neri
2026-04-01 9:30 ` Christian Loehle
2026-04-02 4:27 ` Ricardo Neri
2026-03-30 22:20 ` [PATCH RESEND 3/4] sched/fair: Allow load balancing between CPUs of equal capacity Ricardo Neri
2026-04-01 8:56 ` Christian Loehle
2026-04-02 4:30 ` Ricardo Neri
2026-03-30 22:20 ` [PATCH RESEND 4/4] sched/topology: Keep SD_PREFER_SIBLING for domains with clusters Ricardo Neri
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=20260330-rneri-fix-cas-clusters-v1-1-1e465b6fecb2@linux.intel.com \
--to=ricardo.neri-calderon@linux.intel.com \
--cc=baohua@kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=ricardo.neri@intel.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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
all inboxes | Powered by JetHome®