From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 1A6A937DEBA; Wed, 12 Aug 2026 05:42:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513328; cv=none; b=b23+sBXS+i+dxilG/lBfd1w4lde2N9OaYroNU/IjRzybteatd64dUdUjTOzx3CUmdV52jijKtfREQFtSeFqxMNV26N3yoeD0eyQhoZHUNB8Vr2gXWu5s7ePsrlKv0UD3gSiegXazzzep+Z689lcEE5SjWE/o0eCOf/AMqpDGGbc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786513328; c=relaxed/simple; bh=RyklxcPSP7Qfg2QDFZ/nj8HOB60hUtyDriXJP9+ZYJw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TmLDZ4MBULhJiw3JmU6Ts/2H3oEKc0oNEvgjqyUAvGuIk2tlCEAL1Bma9OkyGGyQwUQ1jVsY91XW8l289RusVqExcElbfQXUeVcKUtonbvjiZhhbV9KXXhJFSjJqtNrSEz0j7+0cKjKbl5fuIbD7eQWjjPjz0GajauzF9wAR8+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=A4/zyx05; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="A4/zyx05" Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67C31co72313501; Wed, 12 Aug 2026 05:41:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=3tg1To8OdOCCr/p31 NSpp5yHMlBFyPnWQDO5YCB6DWk=; b=A4/zyx05bLskf7CitqIpKwXh0YUIWMug5 UHBPgDnp06ToKg8Iaw/polXqUiVHO/wSlXug8KPunXPJWvv2IPJkzY6GbiwnrkKT tMtWJNbNg8PhBPaF1MEaXZuxqK73YxGa8eWJgSZ4EuJ65yvDINBOLq9VUnRzni55 XDkQdJoF05Vux193Sp/RMeYxA5bHzoFPxFNQOAJfdU8u3Ln4W3wHNAFLscwPR3/C uh06Suz6c9Gk+W9nCQpChBPUuvRk2w+/MjnfnxYRq74vIlQfl1eqTihNGlCHVYIy wXAEG93BSy51EqNrF8h1WSmJQxy8lb4HJAIMktrHHbPl8TI2W/Nrg== Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fwvnw87sm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2026 05:41:45 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67C5fGWa010356; Wed, 12 Aug 2026 05:41:44 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4fxh0gcj24-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2026 05:41:43 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67C5fcc019595984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Aug 2026 05:41:38 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3299B20043; Wed, 12 Aug 2026 05:41:38 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 73BCA20040; Wed, 12 Aug 2026 05:41:29 +0000 (GMT) Received: from li-7bb28a4c-2dab-11b2-a85c-887b5c60d769.ibm.com.com (unknown [9.124.217.151]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 12 Aug 2026 05:41:29 +0000 (GMT) From: Shrikanth Hegde To: linux-kernel@vger.kernel.org, mingo@kernel.org, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, yury.norov@gmail.com, kprateek.nayak@amd.com, iii@linux.ibm.com, corbet@lwn.net, meted@linux.ibm.com, ynorov@nvidia.com Cc: sshegde@linux.ibm.com, tglx@kernel.org, gregkh@linuxfoundation.org, pbonzini@redhat.com, seanjc@google.com, vschneid@redhat.com, huschle@linux.ibm.com, rostedt@goodmis.org, dietmar.eggemann@arm.com, maddy@linux.ibm.com, srikar@linux.ibm.com, hdanton@sina.com, chleroy@kernel.org, vineeth@bitbyteword.org, frederic@kernel.org, arighi@nvidia.com, pauld@redhat.com, christian.loehle@arm.com, tj@kernel.org, tommaso.cucinotta@gmail.com, maz@kernel.org, rafael@kernel.org, rdunlap@infradead.org, kernellwp@gmail.com, linux-doc@vger.kernel.org, jgross@suse.com, virtualization@lists.linux.dev Subject: [PATCH v10 06/12] sched/fair: Load balance only among preferred CPUs Date: Wed, 12 Aug 2026 11:10:27 +0530 Message-ID: <20260812054033.95658-7-sshegde@linux.ibm.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260812054033.95658-1-sshegde@linux.ibm.com> References: <20260812054033.95658-1-sshegde@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=RsP16imK c=1 sm=1 tr=0 ts=6a7c0799 cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=VnNF1IyMAAAA:8 a=f1WSfB00kwmd_FHdG74A:9 X-Proofpoint-GUID: mNiVJSpYnpTkyIIJCVecWnCK9FVlxQ_r X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEyMDA0MSBTYWx0ZWRfX77MuemA9o/NU 2dGXoUGyBb6e6FBt3aiR2e87gxUEpYmUlU04W980r4iq9Sr32ENip/G5Pe6zJu9fOaVWR2wmEBx oeUYSxC3ZJIxxP7UsbwvpFkeGIxoZ+zT8CqntwZ/HI//kEkOEjaCEMag5RMDznJwOVF2DNPRJOh 1dw2YOwHRx5AIXMFqv+jaDfYkFLNOTDzIXHMRDWNY7vdtTS91vjoqrUH32mLCY+vjQyEMg9ntjB taZrYjXm5mw7mnDAtqNpkAtKrlcEUZ6W1CSygUhqwUTMiWOAJxLphZ5qIZ0Ssd9hQXEovZRlLRr fCV2UnKLOguENQ8Qc28ZpTToBaJ8kTEZGWKMqy12WfA7sg1/Mkc9tVAQXNMz8k/E8cLdk7LlHA4 z2rZecHUlmWNtbxdN+zb9g7icskU1kzd6LB86nxNvxRI2BJrE8FfBMuO5SZjsrnxiENfr4+WiIx GVXpJnpcdbf63yejaPQ== X-Proofpoint-ORIG-GUID: 9aW2-1L_U2opvLipHrL5XROD2lSmm9YT X-Proofpoint-Spam-Info: AW1haW4tMjYwODEyMDA0MSBTYWx0ZWRfX6MAQbwSScnKx kLzCFq99L2Cgd/+0uf0vkfo3RZJW7qqUt/wnIaABzGA9OaipRespWOHirznO6CWVDvoNxdyjPyq qlhg6SfMSPUeZR7VpirOV+6KkqVu1Z0= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-12_01,2026-08-10_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 impostorscore=0 suspectscore=0 clxscore=1015 malwarescore=0 phishscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608120041 When a CPU is marked as non-preferred, any load pulled towards it is pointless since the task will be pushed out again in the next tick. So, consider only preferred CPUs for load balancing. This ensures load balancing does not fight against the push task mechanism which happens at the tick. Also, this stops active balancing from happening on a non-preferred CPU pulling the load. This also means there is no load balancing if a task is pinned only to non-preferred CPUs. They will continue to run where they were previously running before the CPUs were marked as non-preferred. Bail out early for NEWIDLE balancing, as load balancing is done only on preferred CPUs. Note that idle balancing is allowed to go through, since that naturally updates nohz.next_balance when all the idle CPUs are non-preferred. Also, optimization in find_new_ilb() is skipped. The steal governor driver, which is introduced in later patches, updates the preferred CPUs state in descending order. find_new_ilb() checks for idle CPUs in ascending order. Hence, in most common scenarios, the idle CPU found by find_new_ilb() will already be a preferred CPU. When all idle CPUs are non-preferred, the first idle CPU has to be chosen anyway. All of this is naturally handled in find_new_ilb() currently. Adding additional complexity to it for rare edge cases is not necessary. Signed-off-by: Shrikanth Hegde --- kernel/sched/fair.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index dcf860c59a14..04c2b2e17120 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13429,7 +13429,7 @@ static int sched_balance_rq(int this_cpu, struct rq *this_rq, }; bool need_unlock = false; - cpumask_and(cpus, sched_domain_span(sd), cpu_active_mask); + cpumask_and(cpus, sched_domain_span(sd), cpu_preferred_mask); schedstat_inc(sd->lb_count[idle]); @@ -14544,10 +14544,8 @@ static int sched_balance_newidle(struct rq *this_rq, struct rq_flags *rf) */ this_rq->idle_stamp = rq_clock(this_rq); - /* - * Do not pull tasks towards !active CPUs... - */ - if (!cpu_active(this_cpu)) + /* Do not pull tasks towards !preferred CPUs */ + if (!cpu_preferred(this_cpu)) return 0; /* -- 2.47.3