From nobody Sat Jul 25 01:35:10 2026 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 0C61A37A829 for ; Tue, 21 Jul 2026 02:33:20 +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=1784601202; cv=none; b=k+RL9B0AWOP1PlBLRwat6nCECM5j9ztSojvAuL2g/R56XmS3+WIItuHFRXolnPISAPMcleTszCEg4HtjZRhTXz+9K+Ih4LqD7h5SosCr6EUpZQAd0ftPUCgm0+6tu6kUDF3dV+ERcqIDVaJXujZLAyiIQkncEq5wz2IxFLQfSYs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784601202; c=relaxed/simple; bh=4nequTKog4janh5ttLwSx77eROAMWxxaZLcQli7ww9I=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=OCGMSWne+ctF0s29DYXsNQ1M1AuEl8wfejp+lf//WoJRkGM/dAPnHfjGOwJcuPhijzHj63Ix7uo70Tsu1jdYQAn8hwslfMOXTmjf8IrNOuUjxWyFR/pCJAAc78m1yB8AwvXxVXK9xP6sEC3Owx+UaQI0e31NBYc8nBvcwb7Reik= 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=moH6YXO3; 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="moH6YXO3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784601201; x=1816137201; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=4nequTKog4janh5ttLwSx77eROAMWxxaZLcQli7ww9I=; b=moH6YXO364JHXUP+fQEllJ5kLJqmor/uoVtsJfuaAwa5R/wRVo+n1srO a9HWJdf9EBLwGuD09z6K/4jCagN1WoJSKA/6GN1M1dpYyJGwbjxZhLPVQ o/PZzfohtktCVsdevzrxDthghfk1J3sMaK/GrdVor0F8K8TcyJFomgjxN BspEiMG8fTCsP90e/2k7GtPMRBR+AHirPMXpEjhRRPEa0oILf3Zkh5wiv glC1+qcKSr5IetZwCA4lHVH62cs6S9l5YaHcDGmJe/2uRWToOw4JO+jie VrkjmS1KKqnUHprh41WS1ILe2vk4/Emq/tsbJBo4aPiINinowdfOa0OWV g==; X-CSE-ConnectionGUID: jEeOa7LTSki+cxALCmSFMA== X-CSE-MsgGUID: +3CKtTL7RM2BuKOsfPyXqA== X-IronPort-AV: E=McAfee;i="6800,10657,11852"; a="95785684" X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="95785684" 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:18 -0700 X-CSE-ConnectionGUID: kaB3oi82RLCaF/p7eC5v1Q== X-CSE-MsgGUID: PT98EhOhS82Bxfz8714H+Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="257682257" 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:17 -0700 From: Ricardo Neri Date: Mon, 20 Jul 2026 19:43:17 -0700 Subject: [PATCH v6 1/6] sched/fair: Do not skip CPUs of similar capacity with busy SMT siblings 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: <20260720-rneri-fix-cas-clusters-v6-1-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=2418; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=4nequTKog4janh5ttLwSx77eROAMWxxaZLcQli7ww9I=; b=PsAh9oiJ9hlCiRcOfkOQhuss77b4IRzyhz3MzU1+U8PxYGj5gSXEeSTtwegBIoCXauWuUA5gj A6X+JDxkXIYASYAUIB4HV5rqqlwo3Wc8sGIp975gDNOjow3Bit83IJx X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= When picking a busiest CPU with only one running task, the function sched_balance_find_src_rq() skips candidate CPUs if the destination CPU has less than ~5% extra capacity. This condition only holds if all the SMT siblings of a CPU are idle. SMT siblings share the computing resources of a physical core and this results in reduced capacity if more than one sibling is busy. Skipping a CPU as described would prevent the load balancer from pulling tasks from a scheduling group previously and correctly identified as group_smt_balance (i.e., one with more than one task running). Do not skip a candidate CPU of similar capacity if it has busy SMT siblings. Reviewed-by: K Prateek Nayak Reviewed-by: Vincent Guittot Tested-by: Andrea Righi Signed-off-by: Ricardo Neri --- Changes in v6: * Added Tested-by tag from Andrea. Thanks! * Added Reviewed-by tag from Vincent. Thanks! Changes in v5: * Optimized logic to identify CPUs with busy SMT siblings only when needed. (Prateek, Chen Yu) * Added Reviewed-by tag from Prateek. Thanks! * Christian also provided his Reviewed-by tag, but the patch changed significantly since then. I did not think it was correct to keep it without him reviewing the updated patch first. Changes in v4: * Introduced this patch. Changes in v3: * N/A Changes in v2: * N/A --- kernel/sched/fair.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 37001c63452e..15a0e1ce90b7 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13088,9 +13088,17 @@ static struct rq *sched_balance_find_src_rq(struct= lb_env *env, * average load. */ if (env->sd->flags & SD_ASYM_CPUCAPACITY && - !capacity_greater(capacity_of(env->dst_cpu), capacity) && - nr_running =3D=3D 1) - continue; + nr_running =3D=3D 1) { + bool smt_degraded_cap =3D sched_smt_active() && !is_core_idle(i); + + /* + * Busy SMT siblings reduce the capacity of CPU @i. Do + * not skip it in this case. + */ + if (!smt_degraded_cap && + !capacity_greater(capacity_of(env->dst_cpu), capacity)) + continue; + } =20 /* * Make sure we only pull tasks from a CPU of lower priority --=20 2.43.0 From nobody Sat Jul 25 01:35:10 2026 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 E2D8E3FFFB8 for ; Tue, 21 Jul 2026 02:33:21 +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=1784601203; cv=none; b=CuHwOMcwA48Hs+/0iosvY30CyfjrKPy8ZrkJyoaVQRGBmwTSYj24P37x59ez8eIE4G73NPy9WR/vJY5eKA+aqX4lfdE3G9VnySRfFmt1sOyCNhVSrlHxu9mim6wL8romUfJg7Tk6LTA4+t1nacz3Ch1igfr2E1UPsP3IYKM0Pl4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784601203; c=relaxed/simple; bh=51n49MP98ZOaaSWmGsFPZOcNFmgPzKd2Atz2Upix5g0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=CgAM1jQdI8jTff1aF3P4618oiOzegoDExRSZfmjkY1C8ArV59JTSpO2yFGu1UwcjhhEx/27xP0d2Ht7MlPBt9wnhZNOoyBkB7V5mFm7aybo/BlgCxDgulMhN7h5FutI208tFvIlVPiBHE8UAJ7GuEmJvBFlVhfvLQejcCerp6n4= 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=UgTzkTOK; 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="UgTzkTOK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784601202; x=1816137202; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=51n49MP98ZOaaSWmGsFPZOcNFmgPzKd2Atz2Upix5g0=; b=UgTzkTOKfxGDzy1V5Cf9C/2xtGy4nXz+5SZ7qHvkDYQMkdBmjJYdMVMl xO1SDPd1GtVTazQ2vxCm+Ki9ep1zja+fJ/whaQJsIf8/nnnctMJC/iewL 8uvMTY0ehRY2GW7Is1pkCryxfPQG9DH904FpFL4J+I2L4xF816chJJqcS cqJMo1/R1ILe4b1wijoz0pUHGELJGNTJkwHrH8nLWCkmMyMQMu8usugL/ oKugG8mjJACJ4dlXQV10neUKB7uOfxSE4Vkbp9TwYga610+3NS9LBJNNd hilqIar207u+WSPNnIBYHiD9EuUaF+C0frdWAcRK+o7XwIXnE12iORqEF g==; X-CSE-ConnectionGUID: 9MNbMmy3Stm+9U8JfJU96Q== X-CSE-MsgGUID: KCDHhiA5SRO8WmSztuEu+A== X-IronPort-AV: E=McAfee;i="6800,10657,11852"; a="95785695" X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="95785695" 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:18 -0700 X-CSE-ConnectionGUID: RN4qq8A1Qa6PcF/6IkjYGQ== X-CSE-MsgGUID: ShJANbSNRd+fuZLNCsyGnw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="257682260" 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:18 -0700 From: Ricardo Neri Date: Mon, 20 Jul 2026 19:43:18 -0700 Subject: [PATCH v6 2/6] sched/fair: Also gate overloaded status update for SD_ASYM_CPUCAPACITY 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: <20260720-rneri-fix-cas-clusters-v6-2-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=1742; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=51n49MP98ZOaaSWmGsFPZOcNFmgPzKd2Atz2Upix5g0=; b=ciY1hIrcx02oE6WWUbhc+/Ggp4k6wQzgIfb96jMHg5LMfA1pOFb8fsde7AHDaf9hC184ONdgD uk5UDoQW7CiBJMTVb993mfRORVrl8CB7WgS71+aa9M5SFLUtjo7pmy7 X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= The argument sg_overloaded of update_sg_lb_stats() is only consumed when balancing at the root domain. It only makes sense to update it in such a case. Commit 3229adbe7875 ("sched/fair: Do not compute overloaded status unnecessarily during lb") updated the logic accordingly but missed the case in which the root domain has the SD_ASYM_CPUCAPACITY flag. Fix this. Fixes: 3229adbe7875 ("sched/fair: Do not compute overloaded status unnecess= arily during lb") Reported-by: Chen Yu Tested-by: Christian Loehle Reviewed-by: Vincent Guittot Tested-by: Andrea Righi Signed-off-by: Ricardo Neri --- Changes in v6: * Added Reviewed-by tag from Vincent. Thanks! * Added Tested-by tag from Andrea. Thanks! Changes in v5: * Added Tested-by tag from Christian. Thanks! Changes in v4: * Introduced this patch. Changes in v3: * N/A Changes in v2: * N/A --- 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 15a0e1ce90b7..4e82bc9963e6 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -11975,7 +11975,9 @@ static inline void update_sg_lb_stats(struct lb_env= *env, /* 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; - *sg_overloaded =3D 1; + + if (balancing_at_rd) + *sg_overloaded =3D 1; } } else if (env->idle && sched_reduced_capacity(rq, env->sd)) { /* Check for a task running on a CPU with reduced capacity */ --=20 2.43.0 From nobody Sat Jul 25 01:35:10 2026 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 4F938401494 for ; Tue, 21 Jul 2026 02:33:22 +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=1784601204; cv=none; b=szejvRvY1EL7rAzSKTkMqoNCep/JS/cyWRMfOWJfw6lVcFatOltw2WJrVeXSVo7gkpNyN1/tDLaNEIiXkyDBiCXYFBNjGzzPbYhmCBjbHDaWDuKJgp9ubohWmJOGZjaDmxzrIN1HHUSmpobfJQsi1olZRIX32O0OIDYqXrKXYwQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784601204; c=relaxed/simple; bh=FZHs2jKRxcPPeLOrYIGW71hzJcQhDxvMWag/X5NoLhI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SY7FhHKybY8qPr4f0imnx3NTq36Axwz6jLGPoV0cGjr3nAF+kQ7p1HuZIfVVGsVJQXvopFDjk0KDvDq6Y6OrTa6JuNX5lGJXZyPFNUrwd3X9WErQt4qNVQpJ98tlNtpvucsJ5u3z/IEHMApNE1Kgy29pudnVgZO/vjkwmSV9FhM= 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=NSQe9Ist; 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="NSQe9Ist" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784601202; x=1816137202; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=FZHs2jKRxcPPeLOrYIGW71hzJcQhDxvMWag/X5NoLhI=; b=NSQe9IstrBNdt/71B01BJW5LbGezgHFsYlGb9ygCiB3ga9CDh4gdY1H9 x9r1jEmnQ4hgR9aSLm1flCPsAymeh4Q6Mtme38MnV8G9F1daLE/KZcU8i DEhbTglEXtCCmA1J1a4XVdn8XKoxs0CqyfkzoQV4Bg9Mjg44PEXRHp+2B GRSYX54ZGA2to28dHkL/RHj4OMXgfwhdbAIqAoee8F3urDOFt8bbw2oz3 T8wZ7iyb7Z85OMJErwBG3rHdtnulJfFmBkSb4qcGcNLHgm/EW3wzC2xmy pFZzcvNs4w0WZ6BWWfAMSWHr7Xzq5p5boGUUCngXUmEX0UeHzhh9bSwdh g==; X-CSE-ConnectionGUID: LwOLrrpQTuSvGX6MsB4gCA== X-CSE-MsgGUID: O5wT7cLFS6GJmp19Hhl5nw== X-IronPort-AV: E=McAfee;i="6800,10657,11852"; a="95785706" X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="95785706" 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:19 -0700 X-CSE-ConnectionGUID: /2Udcfr+Rq2SjvvRNWKnyA== X-CSE-MsgGUID: ONh8PW/8SYiORhq/YXu4gQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="257682265" 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:18 -0700 From: Ricardo Neri Date: Mon, 20 Jul 2026 19:43:19 -0700 Subject: [PATCH v6 3/6] sched/fair: Check CPU capacity before comparing group types during 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: <20260720-rneri-fix-cas-clusters-v6-3-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=3276; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=FZHs2jKRxcPPeLOrYIGW71hzJcQhDxvMWag/X5NoLhI=; b=1OC7BBE+U1rdpCuPw9T0/PPmF0xQz0N/hAbTYvY4IU0h9kVQmpIeVp5BkA+8x9O+bEADC+wrq kZKAlM6JpfYA3jjtof6FxIwo/3FJiovhCZwbRIVk6x0FMOBpsLIt9mD X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= update_sd_pick_busiest() may incorrectly select a fully_busy group as the busiest group when its per-CPU capacity exceeds that of the destination CPU. This happens because the type of busiest group is initialized to group_has_spare and allows the fully_busy group to win the type comparison. update_sd_pick_busiest() should not choose a candidate scheduling group with at most one runnable task if its per-CPU capacity is greater than that of the destination CPU. Such a check already exists, but it is done too late: after the type comparison, preventing a subsequent fully_busy group of equal per-CPU capacity from being correctly selected. Move this check to occur before comparing group types. Fixes: 0b0695f2b34a ("sched/fair: Rework load_balance()") Reviewed-by: Christian Loehle Reviewed-by: Chen Yu Reviewed-by: Tim Chen Reviewed-by: Vincent Guittot Tested-by: Christian Loehle Tested-by: Andrea Righi Signed-off-by: Ricardo Neri --- Changes in v6: * Add Tested-by tag from Andrea. Thanks! Changes in v5: * Added Tested-by tag from Christian. Thanks! Changes in v4: * Dropped note on SMT not being affected since SMT + asym capacity is now supported. * Added Reviewed-by tags from Vincent, Tim, and Chen Yu. Thanks! Changes in v3: * Added a Fixes tag. (Christian) * Added Reviewed-by tag from Christian. Thanks! Changes in v2: * Added a note clarifying that SMT and SD_ASYM_CPUCAPACITY are mutually exclusive. (Tim) * Kept parentheses around bitwise operators for clarity. * Rewrote patch description for clarity. --- 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 4e82bc9963e6..9132fcd621dd 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -12056,6 +12056,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 @@ -12162,17 +12173,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 Sat Jul 25 01:35:10 2026 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 CEF6B401A14 for ; Tue, 21 Jul 2026 02:33:22 +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=1784601204; cv=none; b=MEt9sL3YDPlvpPPB+rD9EFxkUySvh9D3hfKwOKQ8ay3TKllKyeClMgoH0rHKEn/MS6gnFcPIBfUYS6joSMeOzf16NJOW9rUKzn73dV2OeXb5xRDe1g40e/VwyoPDyE7K0On02KTuslbbdlWyxvxI+0mkW3bKEq3+A9H3WoBYHm4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784601204; c=relaxed/simple; bh=86j2Mrye6Yx9y1pTwIag7XKL6RLPt2GuxWF55HnG128=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=HGtfO5M3qfeq0PEvGzr1TCB1mvX1hEo1cwCnjhUshuz/TcbILJ4p0/PjRXHN3SAJdnOD9ai/+zk1MElkfygkz4MgWkw2usoc31YG6f/fmVT20XiiIpHPCDrDIk7n/wT/LgKf34giO2Eame4lbLbY2lNxBzrEbtQYUh4RYXx0N8o= 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=BE8edHFl; 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="BE8edHFl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784601203; x=1816137203; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=86j2Mrye6Yx9y1pTwIag7XKL6RLPt2GuxWF55HnG128=; b=BE8edHFlyR6jU0zRiV1JoJmqPgS4e1Wo7Ba6wnVusWfuee4qEn38NLpI NCRqSZ8Fufgvsq4LN3lr4gW7mT2gi3Bcv9DaJxsNBuYKYmJZ4QcNKlV3D IJ05wIEu09VnPN77LM7/spkbPfUOgWqgWdgjTg646XVtH20hYbaxCJCVF hkxJoFJ/tdlEIvZR4fDEQ5vTTHzq1REmwfhz6kd1IHA/4lq7Tg07C8kB6 Q0aEEZC9xjtYhOjq6jnmfmCpBS/R2g+qU5AJPvELANwn9bAvHWLopzzWb eT62vHJw2aVYTfEt+qR+L8ILBSZWGWErajzEl70kArALSVKkvp/8Cg0kw w==; X-CSE-ConnectionGUID: G/PQsprxRYKqa6EkII4DHw== X-CSE-MsgGUID: dugTON93Rbu1BKL5L36k/A== X-IronPort-AV: E=McAfee;i="6800,10657,11852"; a="95785717" X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="95785717" 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: MXmizK55Q1i21+1V0JCXPg== X-CSE-MsgGUID: x0xeJ3ORRJ+/4XCTwro51w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="257682269" 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:18 -0700 From: Ricardo Neri Date: Mon, 20 Jul 2026 19:43:20 -0700 Subject: [PATCH v6 4/6] sched/fair: Skip misfit load accounting when 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: <20260720-rneri-fix-cas-clusters-v6-4-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=3377; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=86j2Mrye6Yx9y1pTwIag7XKL6RLPt2GuxWF55HnG128=; b=o3aEvRMLOC/xygR//0J/gCsK6n6LZxULmKkTkAlRP0wffIeSFU+36X8re7A5OFfvkSPKMnpAl UXyC1AIVlElAmNDUAkeNyY0E+5lLaa055L1pkHWhWdblEVRO5vXGDlt X-Developer-Key: i=ricardo.neri-calderon@linux.intel.com; a=ed25519; pk=NfZw5SyQ2lxVfmNMaMR6KUj3+0OhcwDPyRzFDH9gY2w= In domains with asymmetric capacity, identifying misfit load in a scheduling group is not useful when the destination CPU cannot help (i.e., its capacity exceeds the group's maximum CPU capacity by less than ~5%). In such cases, it also prevents load balance among clusters of equal capacity when CONFIG_SCHED_CLUSTER is enabled. This happens because update_sd_pick_busiest() skips candidate groups of type misfit_task if the destination CPU has similar capacity. Skipping misfit load accounting in this situation allows the group to be classified as has_spare or fully_busy and lets load balancing proceed. Keep marking scheduling groups as overloaded when misfit tasks are present. The sg_overloaded flag propagates to the root domain and allows bigger CPUs in it to help via newly idle balance. Reviewed-by: Christian Loehle Reviewed-by: Chen Yu Reviewed-by: Vincent Guittot Tested-by: Christian Loehle Tested-by: Andrea Righi Signed-off-by: Ricardo Neri --- Changes in v6: * Added Tested-by tag from Andrea. Thanks! Changes in v5: * Added Tested-by tag from Christian. Thanks! Changes in v4: * Added Reviewed-by tags from Vincent and Chen Yu. Thanks! Changes in v3: * Added Reviewed-by tag from Christian. Thanks! Changes in v2: * Moved the check of the destination CPU capacity inside the code block used for SD_ASYM_CPUCAPACITY. v1 inadvertently broke the mutual exclusion of the sched_reduced_capacity() path. * Keep marking the root domain as overloaded to allow bigger CPUs to help. (sashiko) * Fixed patch description to clarify that the capacity_greater() looks for differences of 5% or more. (Christian) * Reworded the patch description for clarity. * I did not include the Reviewed-by tag from Christian since the patch changed functionally. --- kernel/sched/fair.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9132fcd621dd..feea47e6abea 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -11972,12 +11972,25 @@ static inline void update_sg_lb_stats(struct lb_e= nv *env, continue; =20 if (sd_flags & SD_ASYM_CPUCAPACITY) { - /* 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; - + if (rq->misfit_task_load) { + /* + * Always mark the root domain overloaded so big + * CPUs can pick up misfit tasks via newly idle + * balance. + */ if (balancing_at_rd) *sg_overloaded =3D 1; + + /* + * Only account misfit load if @dst_cpu can + * help; otherwise, the group may be classified + * as misfit_task and update_sd_pick_busiest() + * will skip it. + */ + if (capacity_greater(capacity_of(env->dst_cpu), + group->sgc->max_capacity) && + (sgs->group_misfit_task_load < rq->misfit_task_load)) + sgs->group_misfit_task_load =3D rq->misfit_task_load; } } else if (env->idle && sched_reduced_capacity(rq, env->sd)) { /* Check for a task running on a CPU with reduced capacity */ --=20 2.43.0 From nobody Sat Jul 25 01:35:10 2026 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 7616B401A33 for ; Tue, 21 Jul 2026 02:33:24 +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=1784601214; cv=none; b=CsGxdLPYlW7sEozorxsZ5/9YGxK3yjVjtVLtZByZn1XDLp9cjNYF+pUHv45Zcy1WKSlzB9EUQ78yFyiE4dc3L0QsNgd1JaqExb7hAu3CcCma3xqTO/S3efMJ1gBTzehx0siYcDxvddps8kiTikBXd3i7QaKfNDCzBPb6KlSogqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784601214; c=relaxed/simple; bh=jvZf4EC9qkymG2egqu7JR/C8hUMi4y2Ooveld4Tw2Ys=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DXSLoUQkb8c2LF5/Uxpa7N1NtDJrruz+Aaw23un3Xb9r02UaOvXCfASXdyGZy2gMPyvlYs+9+Ui8kuIoQ7Yx/DD/hKFLjy7lF/W99GLb7T0Vs3rrhfGSVsu1AwLKAz/mVWdFCVzykPYEZH51psLttn95lHHUgocKQel/5HD5zhE= 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=IM4fU3oM; 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="IM4fU3oM" 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=jvZf4EC9qkymG2egqu7JR/C8hUMi4y2Ooveld4Tw2Ys=; b=IM4fU3oMNcrz8Eu7VW6TrNAY1Bf+BZ7fteftrrAQcLuJQy8kNtefaRvk D1ZSTNbd7hrzjLN+nLyVDQElnYRlDH/OXS5bBs5eqC1+JmgEBAJF0GRGo L/hw0iXFfUVY7Mx0nTPF4l06QydICvYlly96ISR5e0IqjNVRPhvtVVWty iQX5pkxd2sBupZb9V0GOm6UmnWPqtO3XS+18NSxFKupQgDysQWT22Ybf8 TvPjhMy9Gajb6HCDJg9aeK7CK60g6AOK6+hpjGbCMpzjfJdw1AyLP693t EWl3bMAG9Tywkzm4epet9ZjjuTaZK/FmnRZgbEp/YpNnjXuBkSjeDetlC Q==; X-CSE-ConnectionGUID: Oo+gte9fRACkEcoBaZlPUw== X-CSE-MsgGUID: Co7X+9+GRua9d/hUXsJdFw== X-IronPort-AV: E=McAfee;i="6800,10657,11852"; a="95785729" X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="95785729" 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: I/Q5a6eKSFGJD54DZMA9cA== X-CSE-MsgGUID: K9/6RSFIS9a0xttlX6O9wA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,175,1779174000"; d="scan'208";a="257682279" 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:19 -0700 From: Ricardo Neri Date: Mon, 20 Jul 2026 19:43:21 -0700 Subject: [PATCH v6 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: quoted-printable Message-Id: <20260720-rneri-fix-cas-clusters-v6-5-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=3061; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=jvZf4EC9qkymG2egqu7JR/C8hUMi4y2Ooveld4Tw2Ys=; b=NCsKhy9+Uu1+fZK3SJRHOxjuuIWjvECL168sMtc76UJWDdnoEm8M32eEwRRauRgj8uPlKv1o0 ABwxmE4fgDwCkOUkqOoqcT2i+BwN+aWRL8NS/sR+cRmdIks3x537/lB 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 get_actual_cpu_capacity() to reflect architectural capacity as well as diminished capacity due to hardware or cpufreq pressure. Guard this check with the sched_cluster_active static key so that systems without cluster topology are unaffected. Tested-by: Christian Loehle Tested-by: Andrea Righi Signed-off-by: Ricardo Neri --- Changes in v6: * Switched to use get_actual_cpu_capacity() instead of arch_scale_cpu_capacity(). The former considers rq->avg_hw.load_avg and cpufreq_pressure and their impact on CPU capacity. (Vincent) * Renamed the variable same_arch_cluster as cluster_equal_cap for clarity. (Andrea) * Added Tested-by tag from Andrea. Thanks! 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 feea47e6abea..de4189b562ac 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13104,13 +13104,20 @@ static struct rq *sched_balance_find_src_rq(struc= t lb_env *env, */ if (env->sd->flags & SD_ASYM_CPUCAPACITY && nr_running =3D=3D 1) { + bool cluster_equal_cap =3D static_branch_unlikely(&sched_cluster_active= ) && + (get_actual_cpu_capacity(env->dst_cpu) =3D=3D + get_actual_cpu_capacity(i)); bool smt_degraded_cap =3D sched_smt_active() && !is_core_idle(i); =20 /* * 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, accounting for + * hardware and cpufreq pressure. */ - if (!smt_degraded_cap && + if (!smt_degraded_cap && !cluster_equal_cap && !capacity_greater(capacity_of(env->dst_cpu), capacity)) continue; } --=20 2.43.0 From nobody Sat Jul 25 01:35:10 2026 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: quoted-printable 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 &=3D ~SD_PREFER_SIBLING; - if (sd->flags & SD_SHARE_CPUCAPACITY) { sd->imbalance_pct =3D 110; =20 --=20 2.43.0