From nobody Wed Apr 1 09:45:02 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 344FF3E314C for ; Mon, 30 Mar 2026 22:22:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909347; cv=none; b=iKE1RSyYptxc2AbrcGR7IlOKrWI7f8FZbK/4s6dvOUb11TaxcblC2LobDEchfQGbhltHmX8Sh5RdIr6ZxJm947+2QmC9gVy9b+pvo2YpzsQbw5lOaB+MoX4g3beAE/d/YBfxq+grKcCivAnp52cC8ZVkV3mzRZZ/+uedwxGClCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909347; c=relaxed/simple; bh=7YqlhjvelHHRmIPxxW3bFPLGOmOO13E0rrCXAYV/vfg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=G2P/1qRr6kUFAXKnn8IJWc27BWfiaT5R9mTQNcs5FOhzOqj05JjLZKBRKLQDRn2eeUU82z9+/4lopwk6Zfpv4Xp9T6RifDJZu+/rPboAGpKkC5KWr/LDuNc/7ruKEYSyFXRsWrGb2hxsOkzZJ8RMrySgVojKQeUc+tda1E/XG8Q= 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=OMT8V+S9; arc=none smtp.client-ip=192.198.163.9 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="OMT8V+S9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774909336; x=1806445336; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=7YqlhjvelHHRmIPxxW3bFPLGOmOO13E0rrCXAYV/vfg=; b=OMT8V+S9fZZWaCzwCzJIGrnoq0fs4vOxSXDovZtNGqMvLyvh/lzjYYK9 6peitFNdonfpn9lTqWSKPpvH+i108DCqa5qPrB2RML5icSSPmfUYE+dFv OCsNbpouQlm9DkYRI/inDYAZ6tXSBywSDp61yDA4RW41AkU4sI5nvnbsM tIXWFmWDqJD4n10nODQm26lxqaqRp/AQ2MugHsU94VX1eBxnzYfCKQW1s 8Ep3v7uOHHEW847aeIEozMAKWJIyR1HlREtI0EenP8ys6xhor0JcjwSXW aHYIwDBWj2y/9LUAuO7Ar2+JUngB3CLK4VtyAOIiwuUIA2jGpFQlym4nS g==; X-CSE-ConnectionGUID: rfkqLS99RRSaBvqmYfjmyA== X-CSE-MsgGUID: 96L9V4YpQ0KOO6VlqOlEPg== X-IronPort-AV: E=McAfee;i="6800,10657,11744"; a="86606139" X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="86606139" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:14 -0700 X-CSE-ConnectionGUID: 4D7sXyzjQ2uahjmL1TxXdg== X-CSE-MsgGUID: FSxOR1ALR4SAIhqwS/lBmw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="230242282" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:14 -0700 From: Ricardo Neri Date: Mon, 30 Mar 2026 15:20:35 -0700 Subject: [PATCH RESEND 1/4] sched/fair: Always skip fully_busy higher-capacity groups for load balance 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: quoted-printable Message-Id: <20260330-rneri-fix-cas-clusters-v1-1-1e465b6fecb2@linux.intel.com> References: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@linux.intel.com> In-Reply-To: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@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 , 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=1774909272; l=2176; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=7YqlhjvelHHRmIPxxW3bFPLGOmOO13E0rrCXAYV/vfg=; b=oyFyxIpB4A2DSfAVdwThY8jUGbp1dhcBTO9Nz4VJ5xlYrnbpwnXHQDpbwoxdaMilIXP692IcP mFNAyT5a6SQDmZeMUUfI2/gIP3BG0cMcYXooNLOrRFPoo6eK9LH/RTB X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= 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 --- 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 !=3D group_has_spare)) return false; =20 + /* + * 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 <=3D 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; =20 @@ -10474,17 +10485,6 @@ static bool update_sd_pick_busiest(struct lb_env *= env, break; } =20 - /* - * 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 <=3D group_fully_busy) && - (capacity_greater(sg->sgc->min_capacity, capacity_of(env->dst_cpu)))) - return false; - return true; } =20 --=20 2.43.0 From nobody Wed Apr 1 09:45:02 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 9C7F13E3174 for ; Mon, 30 Mar 2026 22:22:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909356; cv=none; b=mJ/UDtSVqWFv1xoymPk8Qe1DFP2MioRjrMDHYFVLDjbmcT2y5AsrqdP9K3yBCKSOOAtObR6/OC6Yjwtuv87xpb4qkdPPZXUrA8S1vYjO7yur0D3qGfrxCsDSzs3bAhyU4VjUi7l2ySBp1h7FMpmQxNlUDP/o9xZ3N4GVAyXGQ6c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909356; c=relaxed/simple; bh=f64UsPq6wjxSA5DEwGW3ZoYCxNvCsqfGeVpf0rwbeac=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DQUpLgZ0FDC6uwlEK9lzD4vbUTSjOBEDit7zVqoa3wDmGhJ0wiPsUHErQ/lR8PYOn2Unzo2dTzq0xeBf2sbB1hhHF2y5NzfSRlMd7ejKlU+v5VdqzUJrAwow3haAPOtrkFs4BuIGMOP/sH/PJep2rzDEtGta1s+H9LM/fdBzYBw= 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=n+pDHS5b; arc=none smtp.client-ip=192.198.163.9 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="n+pDHS5b" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774909347; x=1806445347; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=f64UsPq6wjxSA5DEwGW3ZoYCxNvCsqfGeVpf0rwbeac=; b=n+pDHS5buTY8JZOkC676PybWFTiP9SzSLQLSrih73+T8B1G9lemuLZZy 6qkorWeVwCk3zOA4wmWX6rIxG9OCgj8Y5UUbWBZe16c2nNcU6ufwluzRu 2s6pkD1OonKUQwuySRClUg2/4mlBELLNoNJc7g+oY5m5vup1utthnVvGn EyW3CmfdGwOOqcMe62aFg18mbNKMokaSLcI6ak1uPcuUDAeuoLdQk6t4a /bJb4o+0vgBCxhD6b+ogI5ddG8Mm+0FHpGcZ2idfgD2+y4iuHAKUL9Iu1 +HDsjmgF9+Bahz8ZaiiAfocKrp4UU5ikBrMtOUZYqesxLBUGjL9zc+NkF g==; X-CSE-ConnectionGUID: qNrxtVVgTf+o9DyXq0uOGw== X-CSE-MsgGUID: Dwx9ZNBxR16T6Be1TVUdhQ== X-IronPort-AV: E=McAfee;i="6800,10657,11744"; a="86606149" X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="86606149" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:14 -0700 X-CSE-ConnectionGUID: IQ1/gXYESnWBtjcIoXsaGA== X-CSE-MsgGUID: zQKVb6hBS5G+ZU5livP11g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="230242285" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:14 -0700 From: Ricardo Neri Date: Mon, 30 Mar 2026 15:20:36 -0700 Subject: [PATCH RESEND 2/4] sched/fair: Ignore misfit load if the destination CPU cannot help 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: quoted-printable Message-Id: <20260330-rneri-fix-cas-clusters-v1-2-1e465b6fecb2@linux.intel.com> References: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@linux.intel.com> In-Reply-To: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@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 , 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=1774909272; l=1642; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=f64UsPq6wjxSA5DEwGW3ZoYCxNvCsqfGeVpf0rwbeac=; b=kVIkG1gTleAbOzgizJ2Ra6yjuTU6xvph4p/S5ORrROp8+lzVnmtXvs4TDpb+tKmtcyJS1bvlf 40AQOFw4nZpA3MPkSPKEdFA/ClPLv12nAkLkyJgMMzQP0CG5QoX5VwD X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= There is no point in identifying scheduling groups with misfit tasks if the destination CPU cannot help (i.e., it has less than 20% greater capacity than the most performant CPU in the group). Since migrating misfit tasks takes precedence over relieving fully_busy groups, identifying a group with misfit tasks causes a destination CPU of smaller maximum capacity to back off (see capacity checks in update_sd_ pick_busiest()) even if it can help: it could help a group of equally small maximum capacity if classified as fully_busy or has_spare. The described situation can happen if a scheduling domain has groups of big CPUs alongside two or more clusters of smaller CPUs that share L2 cache. Load should be balanced between these sets of smaller CPUs when CONFIG_SCHED_CLUSTER is enabled. Signed-off-by: Ricardo Neri Reviewed-by: Christian Loehle --- kernel/sched/fair.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9da5014f8387..3c50ecffa4c7 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10302,7 +10302,9 @@ static inline void update_sg_lb_stats(struct lb_env= *env, if (local_group) continue; =20 - if (sd_flags & SD_ASYM_CPUCAPACITY) { + /* Only look for misfit load if dst_cpu can help */ + if (sd_flags & SD_ASYM_CPUCAPACITY && + capacity_greater(capacity_of(env->dst_cpu), group->sgc->max_capacity= )) { /* Check for a misfit task on the cpu */ if (sgs->group_misfit_task_load < rq->misfit_task_load) { sgs->group_misfit_task_load =3D rq->misfit_task_load; --=20 2.43.0 From nobody Wed Apr 1 09:45:02 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 A006E3E315C for ; Mon, 30 Mar 2026 22:22:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909358; cv=none; b=P8X/QA0UFyggJF//Ca7+kRramvt91djYnY9NrceOaYi/ln/znk/3jnblKwYvYSgGF/PijBceeAvvA70+m+0kNbbTBTbHlyUim9OOnLzrzp1MJymda5UwfR6FFK8X6cSi4N/4wRKwFzHLLo73eRUxkooUXEDxb1exm23hniMRNKA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909358; c=relaxed/simple; bh=9GX3wmoEmfqSCzbnh3QdFetERHUu7YbKgD/DnlJFAg4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=dBMBXBbque1duMaguCXpTIYB0zh2j4nnF3xy5SS86Nuzq8ueK96mssOYhufThdrHQxIGqlYd5TVMMXMJtoDHn/tOQl8u/lQM5lM6n4pwWI7KbDp8cS2SeTKgxaDf1hAsDb6VACROV47LkiibKQmUAalQZ+Fbo1kNq50gftlxgjo= 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=iYIyp1or; arc=none smtp.client-ip=192.198.163.9 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="iYIyp1or" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774909348; x=1806445348; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=9GX3wmoEmfqSCzbnh3QdFetERHUu7YbKgD/DnlJFAg4=; b=iYIyp1orCFeBC5msUyZmYy4EvUXwjUtjbj6Aq2MqY2L8dnq+d/uEbC7U zbGVvozWEkYQ0UU2uXhy7b38SBF35mNbFKGIswmXB/QvuVCf955ONUkmp orpacIwIAyt8gIZanYx9EzQ8Rt91JF+pJPzjxZ84tddJ18R9qftKcOgUz ahU0YQ0E5ziQLKSsTsA8xjA9E58MtI5aNAEOPI+nLHY7vvvj+xVc6pTFj P9ba9KbuBnAiMp5RB6n+qTyvmA3uOdRpWZ1ghlqa9MVnjDhoAJ28KowZt OlHna4TkERyCjesAlmIcDsySrEOorVuQVR3iSgMBeauEvsHHV3yR5KrHZ g==; X-CSE-ConnectionGUID: fUJGPNVVRhqDNLiD+Gt3aw== X-CSE-MsgGUID: hXcqikrSSIu2KqHVvSl/Iw== X-IronPort-AV: E=McAfee;i="6800,10657,11744"; a="86606158" X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="86606158" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:14 -0700 X-CSE-ConnectionGUID: j2/cc7W0S4q/yOF8fNAsXw== X-CSE-MsgGUID: Nv5niQz5TpuhV9Te/g0+7Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="230242290" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:14 -0700 From: Ricardo Neri Date: Mon, 30 Mar 2026 15:20:37 -0700 Subject: [PATCH RESEND 3/4] sched/fair: Allow load balancing between CPUs of equal 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: quoted-printable Message-Id: <20260330-rneri-fix-cas-clusters-v1-3-1e465b6fecb2@linux.intel.com> References: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@linux.intel.com> In-Reply-To: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@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 , 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=1774909272; l=1174; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=9GX3wmoEmfqSCzbnh3QdFetERHUu7YbKgD/DnlJFAg4=; b=6omSPE5ycj1ifEBRhmImWQfRTGWUYrAnklc8kJViRmO7ws1YGLNRK8GQmUHqH5QbEl9XtmZxX ejHUYg23OdaAgtSaOwN+E+xpp/jvOmy5ZJgSPiiSIJZnHGP/EKBwR0+ X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= sched_balance_find_src_rq() is supposed to avoid picking as busiest a runqueue with a single running task since that would result in the task migrating to a lower-capacity CPU. It also prevents migrations between CPUs of equal capacity. Migrating tasks between CPUs of equal capacity helps when balancing load in a scheduling domain in which there are CPUs of different capacity and are grouped in clusters of CPUs of equal capacity that share L2 cache. Load should be balanced among these clusters when CONFIG_SCHED_CLUSTER is enabled. Signed-off-by: Ricardo Neri --- kernel/sched/fair.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 3c50ecffa4c7..a7fd4f1f4348 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -11388,6 +11388,7 @@ static struct rq *sched_balance_find_src_rq(struct = lb_env *env, * average load. */ if (env->sd->flags & SD_ASYM_CPUCAPACITY && + capacity_of(env->dst_cpu) !=3D capacity && !capacity_greater(capacity_of(env->dst_cpu), capacity) && nr_running =3D=3D 1) continue; --=20 2.43.0 From nobody Wed Apr 1 09:45:02 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 B22373E3D90 for ; Mon, 30 Mar 2026 22:22:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909357; cv=none; b=s154XB+YUiw4SGpTByw6vRCjyQcrigpicGjGkPSqocVEYywnlM0RQtM+z8pXC1RTgSuuK7ip93yxPv4r26A4S7eIgSMtoAiEh0hIMSQjo1TXbQxvytgG3v0B+uBdGIMBxL/NL9OK67vARpWRdPgEdEuJMVDHVts+fIaBeUOHMY0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774909357; c=relaxed/simple; bh=SXgoQ1idQ/QAggHeUOTb6B7xD04V/Ud51LpI1El6PZc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=uJ3AJsTWy9QKlCCIWRkm4bBjPbXaN7DY+OyuYQYwT7AwCjrNUHNAPA2U0/Ksj04EvQstX9re+kKYtOD6ntGcYf4ExUgVbcX0GorEWN9z5WFF57FAE1TTxiGbEfyihAB0lgDaGECeb7mbLhpw7yYLBv8OO7tAvv2z8CzIGTODnNY= 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=G5ogtlxG; arc=none smtp.client-ip=192.198.163.9 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="G5ogtlxG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774909348; x=1806445348; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=SXgoQ1idQ/QAggHeUOTb6B7xD04V/Ud51LpI1El6PZc=; b=G5ogtlxGP+KM1blH7JVix97vs9bbwSgkiSLOZ10JjW9dNYWF00+Hxi8c rAGEytGvfqQlSrDIPX+9yvND2sJcJdAEDUFvIeAlc/St5Nrlfue3ZSkAs Tm6qOwaVbgBXj66v/YFL2qdFV0DQFElzi1lks+EA46D7XiC7cvtpMZFjS ltRhVhel/8tEmNTu1Sxo5LLAWhEMvNGXSy2hKGMxlSTSHUCjdb0U4AuRG BldZexkvy1tm66Hh0ViEF/Ww2jNi1g0nrDkzeRb6QzjE/hWWlR6dOHZai aoaStu1UNb4sbVy7COZyy1GD/xCrLyT4pQhiKWaQBg0SM3FXWOTUmELwL Q==; X-CSE-ConnectionGUID: 4JzD5e3EQTSxU8/oCZTrsw== X-CSE-MsgGUID: wMkRRldiQ4GrkXlkofQG5w== X-IronPort-AV: E=McAfee;i="6800,10657,11744"; a="86606168" X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="86606168" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:15 -0700 X-CSE-ConnectionGUID: k9fI1MC6Rfe5jLRftnmkVw== X-CSE-MsgGUID: 2k61cJ5BSAyHM0BksGieEw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,150,1770624000"; d="scan'208";a="230242296" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 15:22:14 -0700 From: Ricardo Neri Date: Mon, 30 Mar 2026 15:20:38 -0700 Subject: [PATCH RESEND 4/4] sched/topology: Keep SD_PREFER_SIBLING for 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: quoted-printable Message-Id: <20260330-rneri-fix-cas-clusters-v1-4-1e465b6fecb2@linux.intel.com> References: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@linux.intel.com> In-Reply-To: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@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 , 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=1774909272; l=1754; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=SXgoQ1idQ/QAggHeUOTb6B7xD04V/Ud51LpI1El6PZc=; b=e35cN2IMWMawDaBSo4ef1md2e/4coc1b8aEH+gVM6QAaj448mDuWMO2dZx+g0dy61Lntfz5B6 llj0soUiw+ABnl3+gddFFeCbthpykLdrATz8tS8+ZMzcIxZqQVtYWOO X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= There are topologies with scheduling domains that contain CPUs of asymmetric capacity and grouped into two or more clusters of CPUs of equal capacity sharing L2 cache. CONFIG_SCHED_CLUSTER requires to balance load among clusters sharing a resource. Keep the 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 the load balancer will prevent migrations from high- to low-capacity CPUs. Likewise, misfit load will still be used to move high-load tasks to bigger CPUs. Remove unnecessary parentheses while here. Signed-off-by: Ricardo Neri --- kernel/sched/topology.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 8e06b1d22e91..61786cfdc78f 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -1689,8 +1689,15 @@ 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. An + * exception to this rule are domains in which there are clusters of + * CPUs sharing a resource. Keep the flag in such case to balance load + * among them. The load balancer will prevent task migrations from + * high- to low-capacity CPUs. + */ + if (sd->flags & SD_ASYM_CPUCAPACITY && sd->child && + !(sd->child->flags & SD_CLUSTER)) sd->child->flags &=3D ~SD_PREFER_SIBLING; =20 if (sd->flags & SD_SHARE_CPUCAPACITY) { --=20 2.43.0