From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (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 717952580F2 for ; Mon, 8 Jun 2026 12:47:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780922844; cv=none; b=fA2/jfIH0AjD1DqwuKnzJdCGNTgiczjCH/kQUX1+jyY/cA8TYERw9qU/nrwev9UuWW51yaE8UAtH1C1weCWrVTKLqzp7su6oDDfs0Ld0Y2F6DCrrVB3kJEdXxzlXLUoaK+vtztwCrLWT8yicsuu/Sg5Mv1qY5zHV70VPgFoGiu0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780922844; c=relaxed/simple; bh=r1Nk88pdY5S+Pk2JO2QN3zMUcMybntvPl69IwxLJ1sk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Y0RYFDCy29r2Zto8hNrs9mqJSuAgtBHIEITkIomkyLwswPWvVHeSPaYADrnW1FEpsUCzatFalwcRU5hvF+td7c+eIp0gNd45dqvFkRMiFy0ETlNI5HQN7qdaP+3e3kIn6d9B8hpYu0Rnymn80Cw9AgeHVoZpUZdVKDM14u0iaTs= 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=TMCZYBZg; arc=none smtp.client-ip=198.175.65.15 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="TMCZYBZg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780922843; x=1812458843; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=r1Nk88pdY5S+Pk2JO2QN3zMUcMybntvPl69IwxLJ1sk=; b=TMCZYBZgKCZhlJPLw0emw0Wd2kR6ZIQggPYe128rF+2CwhVRyqOcPKmX ka5KOCJl0xU6RCLT0WPz4BHU4115/wnELs4hzN2McjEJAs9ILMRvA2Swz qka1yWHwP8rAVXc12Vw875oqntvEQTkjzhG4FELG6ge5SaTRaZRrlfM5s 6ZLsyE99GrMzj9xtwvLhDkhhe5HlpgfMv3D3q3bRxdtgE9py8xgQfCfaE v91S3PBe2l1vbQ4XVlsEw7HnJV1u2zOil6WmY9c/PDFd2J6WudbvN7WK3 7U+XzJTU30yWkLpJnHLw1WJnvibnRZZcVb1r57F3okwzAYmL0K8I7NS/o g==; X-CSE-ConnectionGUID: n1dyBckfTyKk/+52J1/1Gw== X-CSE-MsgGUID: qG7VEeJwSQ+S5xDgSXSi5w== X-IronPort-AV: E=McAfee;i="6800,10657,11810"; a="85281946" X-IronPort-AV: E=Sophos;i="6.24,194,1774335600"; d="scan'208";a="85281946" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2026 05:47:15 -0700 X-CSE-ConnectionGUID: PwWqZgFuRe2Z387dXt+Rgw== X-CSE-MsgGUID: 4ZFUw5gDSjqtECcB2WRtNg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,194,1774335600"; d="scan'208";a="247409326" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by fmviesa004.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2026 05:47:15 -0700 From: Ricardo Neri Date: Mon, 08 Jun 2026 05:57:16 -0700 Subject: [PATCH v4 6/6] 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: <20260608-rneri-fix-cas-clusters-v4-6-1526711c944c@linux.intel.com> References: <20260608-rneri-fix-cas-clusters-v4-0-1526711c944c@linux.intel.com> In-Reply-To: <20260608-rneri-fix-cas-clusters-v4-0-1526711c944c@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" , Andrea Righi , K Prateek Nayak , 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=1780923493; l=3389; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=r1Nk88pdY5S+Pk2JO2QN3zMUcMybntvPl69IwxLJ1sk=; b=8SljkKRSGN/2KgAWz9qAfrsJ6pDAeK0zKSXf1NcYsCwe5zxQtKyuig/Af2HWPTLlmxuMAIpN9 7ZohaLlGGtrAoWjnqBPzip14NMIW6+PTH28En2DhBLI2aW1QZizG+Cw 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. Reviewed-by: Tim Chen Signed-off-by: Ricardo Neri --- Changes in v4: * Added Reviewed-by tag from Tim. Thanks! 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 622e2e01974c..f35203ed52c0 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1995,8 +1995,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