From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFAED39937B for ; Thu, 14 May 2026 18:24:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778783055; cv=none; b=qsG1wcKa46L+YwbBIbsAuGM9lFyvnyIlcVSiZEyC1Y4NheW0JYeyy0+RZLy1eCqi7NNKnZqdmusI6DjYg2UZsHX2/FWW3aC6ZBb3rk1lWFxbllOjW8XaKLiF7WlAmvFtcM+0j3W71ZRkZrAXdnLrMSH9fGqOI2t8+XG0ifK2NHg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778783055; c=relaxed/simple; bh=2iufLt19sQxgbMetRHCWJ/NDIS5fCuPz/ShGG8AGH7k=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=bLDGSKc3R4anuSSyuXqvpDfCC3I88Oq2+ZdgQptx2sF/UM/rSg0MWl3iLsItl7gNjs5zNTRgfMbHuGaIxN6ceaEB3QZa0COVYExBWyVF9iv+k69KQnD81S6+oNXppnySIIaT4sPsqLOWp4iUv+xuFZ9q7sp1xpwQCfh9taY8yXU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=RigaC6Dv; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="RigaC6Dv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778783054; x=1810319054; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=2iufLt19sQxgbMetRHCWJ/NDIS5fCuPz/ShGG8AGH7k=; b=RigaC6DvIEQ+ES/10O2wB6uf0Rkl+N3nTS3XIkY4sk+yJLETfsgwQcHX 6RoMLph0PDTExUKUleiXi6S9yjQ2iPMRenYWBKZj4Xkb28BijgMG0zKnR S5Ka06vpN9W98H3OfiDr731cm9kz/izXm097+zynGuf/QE9PKcXzTgEEV NF+wYOavr7piJ6UaqzsDGneljWTHzokvIwobjbh9vuhGfSHPvbIwgKYL6 4+1zSuA3KPpeZsX3FcRrcKEnQpdjdP6lXCmu9rn18IKevDnSSSeUTVmT/ V1eFEhMP5eQNp7gd6gLdCSEWAooXmQZsJdYG+tqgaz6dvbbmjoTZE2tHx w==; X-CSE-ConnectionGUID: /SuvJjAsS0meHGU6HIKF/w== X-CSE-MsgGUID: YGe6pwnURmC0eoZTwXwYdw== X-IronPort-AV: E=McAfee;i="6800,10657,11786"; a="82303152" X-IronPort-AV: E=Sophos;i="6.23,235,1770624000"; d="scan'208";a="82303152" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2026 11:24:09 -0700 X-CSE-ConnectionGUID: hmFqF/y1R1mhuMXAeMNHnA== X-CSE-MsgGUID: HkR56d8qQV2H/FY4g6ZLrA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,235,1770624000"; d="scan'208";a="234181052" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2026 11:24:08 -0700 From: Ricardo Neri Date: Thu, 14 May 2026 11:34:40 -0700 Subject: [PATCH v3 4/4] sched/topology: Do not clear SD_PREFER_SIBLING in domains with clusters Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260514-rneri-fix-cas-clusters-v3-4-0037869554bd@linux.intel.com> References: <20260514-rneri-fix-cas-clusters-v3-0-0037869554bd@linux.intel.com> In-Reply-To: <20260514-rneri-fix-cas-clusters-v3-0-0037869554bd@linux.intel.com> To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Chen Yu , Christian Loehle , Barry Song Cc: "Rafael J. Wysocki" , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org, Ricardo Neri X-Mailer: b4 0.13.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1778783712; l=3275; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=2iufLt19sQxgbMetRHCWJ/NDIS5fCuPz/ShGG8AGH7k=; b=LVJsUCC2rXmQR2mS9zM9IB3A9Y7qLhjVZabbfiLQFcozEDIm80M8+uy/9odKyueoCUGUaEzjy LcbndD++TNFAhJdKDqOI/Uaxj8QvcYBZ18/FUzQVVaEvuyDOkZ0dtYy X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= Some topologies have scheduling domains that contain CPUs of asymmetric capacity, grouped into two or more clusters of equal-capacity CPUs sharing an L2 cache. When CONFIG_SCHED_CLUSTER is enabled, load must be balanced across these resource-sharing clusters. Do not clear SD_PREFER_SIBLING in the child domains to indicate to the load balancer that it should spread load among cluster siblings. Checks for capacity in update_sd_pick_busiest() prevent migrations from high- to low-capacity CPUs if a candidate group is not overloaded. An effect of keeping the SD_PREFER_SIBLING in domains with asymmetric capacity is that low-capacity clusters with spare capacity can now help overloaded higher-capacity groups. This was already the case for single-CPU groups (see calculate_imbalance() for domains with SD_SHARE_LLC). Once the overloading condition disappears, misfit load will still be used to move high-utilization tasks to bigger CPUs if they have spare capacity. Signed-off-by: Ricardo Neri --- Changes in v3: * Updated documentation of SD_PREFER_SIBLING. * Expanded the patch description to explain the behavior when overloaded groups are involved. Changes in v2: * Reworded the patch description for clarity. * Kept parentheses around bitwise operators for clarity. --- include/linux/sched/sd_flags.h | 3 ++- kernel/sched/topology.c | 14 ++++++++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h index 42839cfa2778..42f74af83b8c 100644 --- a/include/linux/sched/sd_flags.h +++ b/include/linux/sched/sd_flags.h @@ -147,7 +147,8 @@ SD_FLAG(SD_ASYM_PACKING, SDF_NEEDS_GROUPS) * Prefer to place tasks in a sibling domain * * Set up until domains start spanning NUMA nodes. Close to being a SHARED_CHILD - * flag, but cleared below domains with SD_ASYM_CPUCAPACITY. + * flag, but cleared below domains with SD_ASYM_CPUCAPACITY if the domain does + * not have clusters of CPUs sharing cache. * * NEEDS_GROUPS: Load balancing flag. */ diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 5847b83d9d55..a1d048344ea1 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1723,8 +1723,18 @@ sd_init(struct sched_domain_topology_level *tl, /* * Convert topological properties into behaviour. */ - /* Don't attempt to spread across CPUs of different capacities. */ - if ((sd->flags & SD_ASYM_CPUCAPACITY) && sd->child) + /* + * Don't attempt to spread across CPUs of different capacities. + * + * If the domain has clusters of CPUs sharing L2 cache, keep the flag to + * spread tasks across clusters of identical capacity. Checks in + * update_sd_pick_busiest() prevent task migrations from high- to low- + * capacity CPUs for non-overloaded groups. Migrations to a lower- + * capacity CPU can happen if a higher-capacity group is overloaded and + * a low-capacity cluster has spare capacity. + */ + if ((sd->flags & SD_ASYM_CPUCAPACITY) && sd->child && + !(sd->child->flags & SD_CLUSTER)) sd->child->flags &= ~SD_PREFER_SIBLING; if (sd->flags & SD_SHARE_CPUCAPACITY) { -- 2.43.0