From nobody Wed Oct 8 12:35:19 2025 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 843D119992D for ; Fri, 27 Jun 2025 21:45:47 +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=1751060748; cv=none; b=ebifTfN9+ULlZgxUMUXlpEV7Mn625O+epB1yFdeWMM0pEj6rkOCxI0SXq+NSz++mQFfFKoNG4rI/1+m+D/C8L0H4eB1ld3MLdCI3q8D1x4EA9kP2CVGUfr1MRoXiLVdMxQFL05ldNSMper0EsD0Qmr46Rf+jB+vzd+60mFww87s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751060748; c=relaxed/simple; bh=7YqlhjvelHHRmIPxxW3bFPLGOmOO13E0rrCXAYV/vfg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SyktF3cHToHPs8HR84C3G2+2sbrs7libJ+eIXNb5Gr6hoWT5TU2Af2e0Ohq2jkijlgtcHDQ1OCPp2JHvPIjKSq9WeZGD3soZv6CwMNEZZ4mh/SINzQibmhrq3Ml/9m+FG4+r3J+JZc8oe9nwGq9V3IjDEQU9Sv9FhOZqNgbO+t4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=b2aL3zbl; 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=none 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="b2aL3zbl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751060747; x=1782596747; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=7YqlhjvelHHRmIPxxW3bFPLGOmOO13E0rrCXAYV/vfg=; b=b2aL3zbl3ZTks+pJAgZ0EIkCMP5rZhXEa1OB0qU8cvq17XRfHOptXVv1 GtVKeIjR2XriMhknBsLczQ9+l2mMlvPolSrZgB4qf7diRGsQexFFv2VUw jJ5BU+0NN5YSEE34C0x9uaAV8uDtmnMU1rD5o47rwZYCxZOG6ZRSm5Tld 7Vmw9aTkg3o2S9x/L8HRlCAkSJxLXhaacP+si0BUq7urM9oaS/HK7ldq5 B4StB5KWpmMG+cMeZuJP0ZlyjXZadVt+CWbqHD64m0IHmdvp3XrJH3JO6 K6xqYxgCkS1PbRiz3CEwVn6oQ3T9ko7LBZ5Yikk0h3l4/ffVKxBQDX69b w==; X-CSE-ConnectionGUID: 6Muj57jyQ+q8cd9HIAeWxA== X-CSE-MsgGUID: 84hsq0O7RtmN+fYi+xvpPQ== X-IronPort-AV: E=McAfee;i="6800,10657,11477"; a="57063777" X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="57063777" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:46 -0700 X-CSE-ConnectionGUID: Q0XYEZ7rQoSNOap9C+w9Sg== X-CSE-MsgGUID: bl7IABFHStun07tCMa1xXQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="190092826" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:46 -0700 From: Ricardo Neri Date: Fri, 27 Jun 2025 14:45:27 -0700 Subject: [PATCH 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: <20250627-rneri-fix-cas-clusters-v1-1-121ffb50bbc7@linux.intel.com> References: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com> In-Reply-To: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@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=1751060764; l=2176; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=7YqlhjvelHHRmIPxxW3bFPLGOmOO13E0rrCXAYV/vfg=; b=Sb9BplYPGiDxmeREwxAZVNDpA0JTwBBK/X9c9RbOxLd0sUzkiF7m28s5x+xXOFmbREiMlbXRJ BsvnJm//zWSDIDMJElygYm9vrQwSLTqCZxa1FdYKhFehU/RNHFFt8P+ 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 Oct 8 12:35:19 2025 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 786BA1FBCB5 for ; Fri, 27 Jun 2025 21:45:48 +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=1751060749; cv=none; b=FXsRCp5w7Sa+ooaJLq4l6Lg3UrTM2vM92zljsfS4AZ0dxMURG3OimRQsN9P4LKWmSq0JhrEyAcAwSi7h1LBhc5t5Z7coMEMDIm+yfVAuw2w9X/AtM/bB+kK3W+/mwT90R5nA6Fr+2YSQsRQGizoVxb5LwfbLqQSSCiPYM0WvmD8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751060749; c=relaxed/simple; bh=f64UsPq6wjxSA5DEwGW3ZoYCxNvCsqfGeVpf0rwbeac=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=YvDhjO6uM4ARikAhC+NEJWa/zcbYHaDmt5VM15ZCXEUL2pmKApsqQlHF1kBAOrTEycos0yAWk7NoRo6qrCujmsMVqwql7ftB6syQhIOkW9ISjVRdOQSNWIhXCRiD00kUA9S+IN/X63msMmuGde9wTWVZ5yOaohv+3lRdxDii+iM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=k7xHO4v1; 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=none 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="k7xHO4v1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751060748; x=1782596748; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=f64UsPq6wjxSA5DEwGW3ZoYCxNvCsqfGeVpf0rwbeac=; b=k7xHO4v1w59A7vhmgmZE82v+jV6Uh4+P8kjY1I0/gkTCqDrpS2Q4Id8U QZJWJekruE/7pHWgohsZsW2d3wJCC0wQLFlrD06m3HfDg5Ewq0DAGRHDH IoGxCT2JH02uZOKaBM03/pHWQ9HC847gXS20W25Uofg8NiSVr9g1QePnT l6h8KOzk1/HQUldFZjg6VmJDtBLR3HZtF02BcsjRiIwZNOnVbdDpfwPga +ic2W5bLhRQYgjZgWrG53bQTyvVDwtenW7LnfCChEg6DjEeu1PPfUDLao y/WDPtXqjNKwm/FUeEalsBcDICx1zssiDkfyw6z0hAQukibZMYNdBj+MZ g==; X-CSE-ConnectionGUID: zo1w0zEST+KdaO0rxlHrrA== X-CSE-MsgGUID: c065NwrbRX+BQl8LWUCO+g== X-IronPort-AV: E=McAfee;i="6800,10657,11477"; a="57063786" X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="57063786" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:46 -0700 X-CSE-ConnectionGUID: EJfiIypERnaUyQk0l0yQGQ== X-CSE-MsgGUID: eeU7k8/XT5OGXxaB3NoQNw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="190092832" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:46 -0700 From: Ricardo Neri Date: Fri, 27 Jun 2025 14:45:28 -0700 Subject: [PATCH 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: <20250627-rneri-fix-cas-clusters-v1-2-121ffb50bbc7@linux.intel.com> References: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com> In-Reply-To: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@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=1751060764; l=1642; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=f64UsPq6wjxSA5DEwGW3ZoYCxNvCsqfGeVpf0rwbeac=; b=v+jvgzjlv3UeMWH9QFvZH/oQKs5LTSAzHcWSONOngAFUeZj73IQrzLaRs3xsUoLepEdXz9n6/ WL13M0ox+zNCW+sK87pJBvfoi0XiG1Ntc4cnqTVeso6rhda0cucJXYz 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 --- 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 Oct 8 12:35:19 2025 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 D457D28A1C7 for ; Fri, 27 Jun 2025 21:45:48 +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=1751060750; cv=none; b=G6kU65dWLWht8Udxrb9vKHnifsJhAICham7lGCP4TTsmVPMf82kMi8tjo5F8KrZPhTTeM9HstCY8BW3VcpJgkblDe6kl4FNeXF46MJrwdccekS12CMOTHtnY35zDKAVgkQ1WO/75WH293+M66PCcbEjNbaD9MAQrpydFxuFyiVA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751060750; c=relaxed/simple; bh=9GX3wmoEmfqSCzbnh3QdFetERHUu7YbKgD/DnlJFAg4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=bFZZFJkHmkKmU62kbQNqdNUvF1I6vTIj1PIvBcrSr3L9FxGglqEbFeJa4fPfcvcTfiwLGbz6KKaGYa5ZtEnSeiPwoahW6njvwdfgqcZYvThIJjMAwU/mFiLZp664eDlTG9mFAWNljFTn2uxJN38CpgA+8nsqPBioDoeyz9oRVAE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WN8u1y+t; 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=none 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="WN8u1y+t" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751060749; x=1782596749; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=9GX3wmoEmfqSCzbnh3QdFetERHUu7YbKgD/DnlJFAg4=; b=WN8u1y+tboTg4Wxce0YHwpSxOCqsE1rTfeP3pTtkSFeyPYkhOjHu5AZv XhFAlgcHleeJ0FK/VfE/1UYc3YpdUBL7D/vN/SDHHLkFyvCeCVdd0FIuT STl5I2OjbqJGPywl0di1AH74wl6uEca+OAsvbHIqhs3MHYE0dgQSCIK8/ r3kCYKORMSRiM7QrlmpSC/SuZeCkZDCzC1gC2rerK176WK4wclc9zNWBS x/2xjUuyKMhHHYDrnkVTlW6d+A0Uq0tSECODyJiKmicdJZkK46v4aJibf 3m5qMxCZTEkg6bk7ZWHEEeKA3EGPf1zXKfT0gJ0euLUzwndHnuEYTy+Q2 w==; X-CSE-ConnectionGUID: TO4kALWgTneXqeMXLl7mKQ== X-CSE-MsgGUID: /LB4OVq4SXKYRzSnlghHkA== X-IronPort-AV: E=McAfee;i="6800,10657,11477"; a="57063795" X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="57063795" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:47 -0700 X-CSE-ConnectionGUID: kta/k6nuR2K6TAbYkFO7jw== X-CSE-MsgGUID: SPWyOUGtTDGxQZrchFHUvQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="190092837" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:46 -0700 From: Ricardo Neri Date: Fri, 27 Jun 2025 14:45:29 -0700 Subject: [PATCH 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: <20250627-rneri-fix-cas-clusters-v1-3-121ffb50bbc7@linux.intel.com> References: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com> In-Reply-To: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@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=1751060764; l=1174; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=9GX3wmoEmfqSCzbnh3QdFetERHUu7YbKgD/DnlJFAg4=; b=i3a2m59+Tyx9minyOdIrTmzd7sy+1MpFhNgUt2NuLAIahVFS8IVMhhOg6g+Mdr6w7g8alZDcE 536p9VgtFzPClmz8d+6mb/AJzF9qKVwfNO/CktWjyVS3AJpXc8VGvbC 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 Oct 8 12:35:19 2025 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 11BDC28A1FB for ; Fri, 27 Jun 2025 21:45:49 +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=1751060751; cv=none; b=mk5//+lkTVD6F2533HZSWjB4s0yOFRw9QdDAtoTGeH0oV8kQfBGwPURS7tudZ1kNY9c28SRJxDfIMia4jzK1y+sCfpOxndh+lXoZGPTL2Z19l2XpZ2ORfmhC3HBw5Wze0xGsgAcMAe3kgW5f0w+W9LqLJwfK7qTTMkRzs9n+Ei0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751060751; c=relaxed/simple; bh=SXgoQ1idQ/QAggHeUOTb6B7xD04V/Ud51LpI1El6PZc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=mhbNqfpqjC4ajX31RGtzVKzNemxR+sHWA7fsm7vtCkIDzprVExvLsbpxTchgnfbBUP6VU6Zhev7kZWaYenv7WowKUPPzHHJtPn460ItOMIUjKoiauzC83vjXPiIIAJHQUNUwWTPA3mIIWBwqvnMSk2QAX6318Fhf4nIYPUfsucM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Yd+1CupH; 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=none 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="Yd+1CupH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751060749; x=1782596749; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=SXgoQ1idQ/QAggHeUOTb6B7xD04V/Ud51LpI1El6PZc=; b=Yd+1CupHB6EFZyOLkPrmPy/CJNxOVoyWojLzircAe6qk/FpAM+vko0V/ Zy9QfCQgeu1iZmJa9IxXNOojZckTU7SFZ7Q4uosQmuHZEYwppHXHnh48O 4kS70kVHQkyBP2fN3brLiDHCOQFNLrHRR8M71tEhQNljMpO5hjxPZGyie +AnZrT1DCm7Jc/iADzJ6G97UaGyttgQHPP37JOwB95VEPp/FGdp9VvqFp udwooULa/grtvadxl/jXb51R39P34pUO1568FwGZPTTz1+GfnixpjRPku G+8BLcVS/e5MkkJ+D48tfWZ8FqaZNR/A1TEUrh24X8nwppva0Dr5a9o+K w==; X-CSE-ConnectionGUID: ZYpSJf67T7y9sVDuIKVPVg== X-CSE-MsgGUID: MeZUQOcRRhCT6KZzqepUpw== X-IronPort-AV: E=McAfee;i="6800,10657,11477"; a="57063809" X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="57063809" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:47 -0700 X-CSE-ConnectionGUID: PVgiLh26QASebbFsDd+gMA== X-CSE-MsgGUID: 8MmuCRbaTN2yssdus7W7dQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,271,1744095600"; d="scan'208";a="190092872" Received: from unknown (HELO [172.25.112.21]) ([172.25.112.21]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2025 14:45:47 -0700 From: Ricardo Neri Date: Fri, 27 Jun 2025 14:45:30 -0700 Subject: [PATCH 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: <20250627-rneri-fix-cas-clusters-v1-4-121ffb50bbc7@linux.intel.com> References: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com> In-Reply-To: <20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@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=1751060764; l=1754; i=ricardo.neri-calderon@linux.intel.com; s=20250602; h=from:subject:message-id; bh=SXgoQ1idQ/QAggHeUOTb6B7xD04V/Ud51LpI1El6PZc=; b=Zu4su9EKrTEx4BlG79NOL/rURGcBoHIzn3WokFj1mO43ZaORCJ3I7yTHMPDm0g5JpEa/UyqJ3 D8DQUFnVh8HAzaMKuzf1ZpMbCj3+bcUR4765BIVeCoOYJDCzEc947Oa 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