From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (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 DA006401492 for ; Tue, 21 Jul 2026 02:33:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784601216; cv=none; b=eLmn4uUnyVSD4QgFmBTBJSmjRTdK0gykrI5QmI9CWQnGJMbA9V0O81L8fwC1SQYmquUrchYx/aIUZun8Lnt0WG4DxvQVWqVODuE2cm4VK9rvyHLDGY82levavFouw9KALxygbn7uWZj99T8Lv+4OtSlkEf/H7657PznDn5Dz7Ko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784601216; c=relaxed/simple; bh=Rau2cdxfa0rt1ddqY3hSPHDf2xUiuOBdZ9Qs6669f90=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=rK2SrBA8b7DseCQxzL6uYjpvr9WrSfzZ5lQAqlXwquPAeFXYRWDwBglFGLwkuwiKUCmseNRte1PcLTSL0r19B5+zhI31N2+IT+w30W2gFRAaP6PBNKiqQ0/T0HByURWWwx28PxUMEBfMNmPk/7dbGwBNg9sgvroYuBPWAsDlQI8= 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=m62FgHiE; arc=none smtp.client-ip=192.198.163.11 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="m62FgHiE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784601204; x=1816137204; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=Rau2cdxfa0rt1ddqY3hSPHDf2xUiuOBdZ9Qs6669f90=; b=m62FgHiEOs/V+DqNxB9WNa/TNh/FwAD4ljvcEX98JTK+RgSWP6FU76ca /BMZ/1nBia5M9ZujVl8FJ2/sAOeAb0C5bl3PuSTEkOBSI4FPb+T17gg55 zXuvj4VL+Gp/UIIaUwSFmp0gpn2V5cbFt3GCRPkHdj0q5fiDeA6o5n+6w yN2qfyh4CPjXiVHwTSUD4Y9WtHgaGp3rRTEPqdhGQtI7kBMGiAC82OPI/ 46g4hVdZqDrWII5FTokDOn8Fsj2f/aD0nIN6rJ3Y2zWGdDqRUx5Dcnj8h 0725VI2QUQ2SNfrEX5CXv2GIc6+fSBlROSipxJvrZf/u7bJkYGcMHzh9I A==; X-CSE-ConnectionGUID: 1g6lY/a/RGSZylX6ePVTpw== X-CSE-MsgGUID: GJH7zRaRTF28AGAT9xXTlg== X-IronPort-AV: E=McAfee;i="6800,10657,11852"; a="95785741" X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="95785741" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2026 19:33:20 -0700 X-CSE-ConnectionGUID: ptxP2CIKSaCjgDoDhQZ8Zg== X-CSE-MsgGUID: JEXVAiq+Qt21dBwKgNmDyA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="257682283" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2026 19:33:20 -0700 From: Ricardo Neri Date: Mon, 20 Jul 2026 19:43:22 -0700 Subject: [PATCH v6 6/6] sched/topology: Restore SD_PREFER_SIBLING in domains with asymmetric capacity 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: <20260720-rneri-fix-cas-clusters-v6-6-bb500bf4afd4@linux.intel.com> References: <20260720-rneri-fix-cas-clusters-v6-0-bb500bf4afd4@linux.intel.com> In-Reply-To: <20260720-rneri-fix-cas-clusters-v6-0-bb500bf4afd4@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 , K Prateek Nayak , Andrea Righi , 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=1784601848; l=3611; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=Rau2cdxfa0rt1ddqY3hSPHDf2xUiuOBdZ9Qs6669f90=; b=vxNZExLaXh1N3T2mbsOkl9Aj3xnTrmokuQXwWNNRX6czCNuLmdZrVKzwIFkkint8mvAfTbT8C oRKr1Csnnw2AXeqXxa6pd9ag1AkJEqRxdE+3wGlHIC3V271n8mjaxOL X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= Commit 9c63e84db29b ("sched/core: Disable SD_PREFER_SIBLING on asymmetric CPU capacity domains") removed the SD_PREFER_SIBLING from the domains with asymmetric capacity. This was done to avoid spreading tasks to sibling scheduling groups with less capacity, but this does not happen: checks for capacity in update_sd_pick_busiest(), sched_balance_find_src_group(), and sched_balance_find_src_rq() prevent migrations from high- to low-capacity CPUs if the busiest group is not overloaded. The cluster topology is a notable example: some systems have scheduling domains spanning CPUs of asymmetric capacity, grouped into two or more equal-capacity clusters sharing an L2 cache. When CONFIG_SCHED_CLUSTER is enabled, SD_PREFER_SIBLING is needed in the domain to spread load across these clusters. CPUs with spare capacity, big or small, have always helped overloaded groups. Once the overloading condition disappears, misfit load will still be used to move high-utilization tasks to bigger CPUs if they have spare capacity. Adding the SD_PREFER_SIBLING flag shifts load balancing in shared-LLC domains from equalizing the number of idle CPUs to equalizing the number of running tasks. This enables migrations among clusters from newly-idle load balance, where the outgoing task is already dequeued but the CPU has not yet transitioned to idle. Tested-by: Christian Loehle Tested-by: Andrea Righi Signed-off-by: Ricardo Neri --- Changes in v6: * Extended the patch to keep SD_PREFER_SIBLING in all asymmetric topologies. (Vincent) * I removed the Reviewed-by tag from Tim, since the updated patch is significantly different to what he reviewed. I am happy to re-apply the tag on an updated review. * Added Tested-by tag from Andrea. Thanks! Changes in v5: * Improved inline comments for accuracy. * Added Tested-by tag from Christian. Thanks! 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 | 4 ---- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h index 42839cfa2778..dc3ec2452ee1 100644 --- a/include/linux/sched/sd_flags.h +++ b/include/linux/sched/sd_flags.h @@ -146,8 +146,7 @@ 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. + * Set up until domains start spanning NUMA nodes. * * NEEDS_GROUPS: Load balancing flag. */ diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 622e2e01974c..21e816ad23ee 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1995,10 +1995,6 @@ 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) - sd->child->flags &= ~SD_PREFER_SIBLING; - if (sd->flags & SD_SHARE_CPUCAPACITY) { sd->imbalance_pct = 110; -- 2.43.0