mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 0/4] sched: Fix cluster scheduling in the presence of asymmetric capacity
Date: Mon, 30 Mar 2026 15:20:34 -0700	[thread overview]
Message-ID: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@linux.intel.com> (raw)

Cluster scheduling balances load among clusters of CPUs sharing a resource
[1]. It was broken on Intel hybrid processors using asymmetric packing of
tasks. Tim fixed that [2]. It is broken again when combined with asymmetric
CPU capacity.

The diagram below shows a processor with big (B) and small (s) CPUs. Also,
small CPUs are grouped in cluster sharing mid-level cache. This topology is
common in Intel hybrid processors.

         ------   ------
         | B  |   | B  |   -----------------   -----------------
         |    |   |    |   | s | s | s | s |   | s | s | s | s |
         ------   ------   -----------------   -----------------
         | L2 |   | L2 |   |      L2       |   |       L2      |
         -------------------------------------------------------
         |                          L3                         |
         -------------------------------------------------------

On a partially busy system (one with idle CPUs; busy CPUs have one task
each), scheduling for asymmetric capacity ensures that misfit tasks are
placed on the big CPUs. The remaining tasks, misfit or not, run on the
small CPUs. If CONFIG_SCHED_CLUSTER is enabled, these remaining tasks
should be evenly spread between the two small-CPU clusters.

This does not happen today because various checks in the load balancer
prevent a small CPU in one cluster from pulling tasks from another:

  * A bug in update_sd_pick_busiest() causes it to not check for capacity
    when preferring a fully_busy big CPU (which it cannot help) vs a has_
    spare small-CPU cluster (which it can).

  * Accounting misfit load in a group is pointless if the destination CPU
    is equally a small CPU. Moreover, update_sd_pick_busiest() will not
    pick such group as busiest anyway.

  * Once a busiest group has been identified, sched_balance_find_src_rq()
    will refuse to migrate tasks to CPUs of equal capacity.

  * The SD_PREFER_SIBLING flag is removed from scheduling domains with
    asymmetric capacity.

I address these issues in this series. Details are in the changelog of each
patch.

I tested these patches on an Alder Lake system with Hyper-Threading
disabled. I also tested with CONFIG_SCHED_CLUSTER=n to ensure that
processors without clusters continue to work.

[1]. https://lore.kernel.org/r/20210924085104.44806-1-21cnbao@gmail.com/
[2]. https://lore.kernel.org/r/cover.1688770494.git.tim.c.chen@linux.intel.com/

---
Ricardo Neri (4):
      sched/fair: Always skip fully_busy higher-capacity groups for load balance
      sched/fair: Ignore misfit load if the destination CPU cannot help
      sched/fair: Allow load balancing between CPUs of equal capacity
      sched/topology: Keep SD_PREFER_SIBLING for domains with clusters

 kernel/sched/fair.c     | 27 +++++++++++++++------------
 kernel/sched/topology.c | 11 +++++++++--
 2 files changed, 24 insertions(+), 14 deletions(-)
---
base-commit: e51a38e71974982abb3f2f16141763a1511f7a3f
change-id: 20250620-rneri-fix-cas-clusters-bb4287d1e152

Best regards,
-- 
Ricardo Neri <ricardo.neri-calderon@linux.intel.com>


             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 Ricardo Neri [this message]
2026-03-30 22:20 ` [PATCH RESEND 1/4] sched/fair: Always skip fully_busy higher-capacity groups for load balance Ricardo Neri
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-0-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®