From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 9969437267A for ; Mon, 22 Jun 2026 23:55:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782172545; cv=none; b=qKylTeA+6Ta0Be1GfHlGr/H45KF3DdbmYmlZfqNyS5MtQdRPWla9pb7LDgY0CA7yjNM3PM7nt3czLk0MsXzOU/5XxxutII3v6chKserTEzfDDmkF7/MyFutJ2MFsGSKQVmEkVr2mqpNLvJcMBy/Tm7lFfxiiCuMrBIAWXahCZS4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782172545; c=relaxed/simple; bh=s1L8PZtBTG0G0ZvPFpeJy8t6uKj4ioQP+QTgcaxGoiM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Bsevl7wmFKcO/0P812LhldbUZzv4JdmVUZAYQlzoK3ck3eC31jZC/azBYVB1jU2cD3VZ7HQZ4Q6CbSpVKyNdvMKtiq34XF+W8gjCJfP2S4Q6tjoLqq2brnlX2XPsCKZtHjVI/G3L5DI0rzmvxpb6s0p+o3hBhCbA/z5sY5A2gnE= 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=NhkKDUJO; arc=none smtp.client-ip=192.198.163.18 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="NhkKDUJO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782172537; x=1813708537; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=s1L8PZtBTG0G0ZvPFpeJy8t6uKj4ioQP+QTgcaxGoiM=; b=NhkKDUJOclNy7/FvHL/gs7NHp7WfRF8k8sPeiucp78oZP9rJO4Bs4XF9 Pi5KsPBMnEN3uFfXVDcBQVgaUSvE64S1F2GyMbor2ZN4k6Ig1l3ivcKsL stmgeWrFEFUpqJzW3HU7YZ/+POyK//Q3bzQ/DgnkxxORcj6/EoR1aXKDp wd1bIHR9QLpPDLZ2qeShO28IHp4cey0rDqpoaEnkJBjpUDCKmziCc55l9 Fb0ShTtxa+DwutH/eC8pKqVIbbZ9l5TqGaILcUlD6NUDnYZ+J7uWf5GcI z+Q6GGXsn70dRAFnxn9s7MV1Szo+ZRdT+cQKtvqryy9rAC2ZnX7G/b5JC g==; X-CSE-ConnectionGUID: bnrYiv6RT3a+PnvXjo2otg== X-CSE-MsgGUID: Ij8if79fQ4e46dcSQtkPFQ== X-IronPort-AV: E=McAfee;i="6800,10657,11825"; a="82014518" X-IronPort-AV: E=Sophos;i="6.24,219,1774335600"; d="scan'208";a="82014518" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2026 16:55:31 -0700 X-CSE-ConnectionGUID: myzI0vfIR5iuDnattPJwbA== X-CSE-MsgGUID: gTohNCbMSl6cqEqgsIUL0A== X-ExtLoop1: 1 Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by fmviesa003.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2026 16:55:30 -0700 From: Ricardo Neri Date: Mon, 22 Jun 2026 17:05:55 -0700 Subject: [PATCH v5 5/6] sched/fair: Allow load balancing between CPUs of identical 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: <20260622-rneri-fix-cas-clusters-v5-5-19968f2d1497@linux.intel.com> References: <20260622-rneri-fix-cas-clusters-v5-0-19968f2d1497@linux.intel.com> In-Reply-To: <20260622-rneri-fix-cas-clusters-v5-0-19968f2d1497@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 , Barry Song Cc: "Rafael J. Wysocki" , Andrea Righi , 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=1782173185; l=2681; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=s1L8PZtBTG0G0ZvPFpeJy8t6uKj4ioQP+QTgcaxGoiM=; b=wbRS4jz7m9MzVZI8ncsDxP/0MRb/yaGOs6ImYtpI66iDokNqp+z/2jtAlPsyWjWsHsJrC1hGT jPUCDRnhwuwD3h8wRlbmA+M2aGqYGyY3BgbGUC063rLeXyOhGuajCzW X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= sched_balance_find_src_rq() avoids selecting a runqueue with a single running task as busiest if doing so results in migrating the task to a CPU with less than ~5% of extra capacity. It also unintentionally prevents migrations between CPUs of identical capacity. When CONFIG_SCHED_CLUSTER is enabled, load should be balanced across clusters of CPUs with the same capacity. Allowing migration between CPUs of identical capacity is necessary to meet this goal. Use arch_scale_cpu_capacity() to reflect architectural capacity, excluding runtime reductions due to side activity or thermal pressure. Guard this check with the sched_cluster_active static key so that systems without cluster topology are unaffected. Tested-by: Christian Loehle Signed-off-by: Ricardo Neri --- Changes in v5: * Optimized logic to identify same-arch clusters only when needed. * Added Tested-by tag from Christian. Thanks! Changes in v4: * Implemented the check for cluster with a local variable for improved readability. Changes in v3: * Reverted the inverted capacity check; the inverted form incorrectly allows migrations to CPUs of slightly less capacity. * Guarded the check for architectural capacity with the sched_cluster_active static key. Changes in v2: * Used arch_scale_cpu_capacity() instead of capacity_of() to ignore runtime variability. * Inverted the check for runtime capacity. (Christian) * Reworded patch description for clarity. --- kernel/sched/fair.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e55eb019d2c9..f4eb55cad54d 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -12992,13 +12992,20 @@ static struct rq *sched_balance_find_src_rq(struct lb_env *env, */ if (env->sd->flags & SD_ASYM_CPUCAPACITY && nr_running == 1) { + bool same_arch_cluster = static_branch_unlikely(&sched_cluster_active) && + (arch_scale_cpu_capacity(env->dst_cpu) == + arch_scale_cpu_capacity(i)); bool smt_degraded_cap = sched_smt_active() && !is_core_idle(i); /* * Busy SMT siblings reduce the capacity of CPU @i. Do * not skip it in this case. + * + * CONFIG_SCHED_CLUSTER requires balancing load across clusters + * of identical capacity. Use architectural capacity to ignore + * runtime variability. */ - if (!smt_degraded_cap && + if (!smt_degraded_cap && !same_arch_cluster && !capacity_greater(capacity_of(env->dst_cpu), capacity)) continue; } -- 2.43.0