From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 160EA322B84 for ; Mon, 5 Jan 2026 05:08:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767589687; cv=none; b=TqwxMw6ew6uX2o7QY1vf0noYXdclOTNtlddD0QDNhL9enOx/AzeVVlscBZblXsmbjAklGJRIb7oAc6a8vcRnKamqCfORdI4ye94RMZBDxqvF25VXEwkOLAHby4yuwIMTJZrhoQYBGRSLRlpkS150W8DeKNrMsx+xKUCZW/RD90U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767589687; c=relaxed/simple; bh=7puQCyyOk1bJXG/jhSM0MLyM6jjjjqyx8r8w33mJeC8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=obsi/JfsV/JitjJfnlMfQUKCIs0xGhfJ9M2cJqX8Ilnz+zwj5IGKxAngq8UEH/PGlUakV6szzV+z9H8Mtj8L1+LptKlTKflg1q34SJiWLjM8E2fphkmmEy+YZIoh+C+0rXm8sdvjatfpPCiNuKofSfGj4MqxSLVTVI8sQopPwG4= 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=cJUdT0PV; arc=none smtp.client-ip=148.163.156.1 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="cJUdT0PV" Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 604Lud8Y011922; Mon, 5 Jan 2026 05:07:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=rbuHbc 7LUX6dMmQjfPcf2ylYlGQOUa7QxuBpMaF8mWA=; b=cJUdT0PVI0LdEX2GwmqR4j LMDlit4jwJpdxlgty8x8319ZvntwJEVu5rOajVI+I+ENVcuaPJ20xUV0+h5Ef1/d EACpolf1D28GAGbiZ+vvqJNvyEpxMYQyGtae3x12ooXheMSGN7wb6Ya38t/goN4V 1WuUjkPeaMuQ1AAzOzzKW/VMxWikFZyb8lwwPTu5aLFo4On2jKtb4kho7o8OJo1M g96WW1HZUpY0iEvlVVuQ2qJTHMBJITOZBpHTRTWQpIG8ECgRjUPQwQ2MEEioUDuc FqDhP7nvM+CpzEOPuY9nDTk99YE+po0thCUQa2Wxpy2P23x0a28Nc+QYzgiuPiVw == Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4betu5wjym-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Jan 2026 05:07:33 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 60547020019337; Mon, 5 Jan 2026 05:07:32 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4bfg50ur29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Jan 2026 05:07:32 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 60557UUF28705460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 5 Jan 2026 05:07:30 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6F73220043; Mon, 5 Jan 2026 05:07:30 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E509E20040; Mon, 5 Jan 2026 05:07:27 +0000 (GMT) Received: from [9.39.29.28] (unknown [9.39.29.28]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 5 Jan 2026 05:07:27 +0000 (GMT) Message-ID: <880e3610-dbdb-42a8-9ddb-ab2e7d3cdc1f@linux.ibm.com> Date: Mon, 5 Jan 2026 10:37:27 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] sched/fair: Change likelyhood of nohz.nr_cpus and do stats update if its due To: K Prateek Nayak Cc: linux-kernel@vger.kernel.org, juri.lelli@redhat.com, vschneid@redhat.com, tglx@linutronix.de, dietmar.eggemann@arm.com, anna-maria@linutronix.de, frederic@kernel.org, wangyang.guo@intel.com, mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org References: <20260102124744.360872-1-sshegde@linux.ibm.com> <20260102124744.360872-3-sshegde@linux.ibm.com> Content-Language: en-US From: Shrikanth Hegde In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Authority-Analysis: v=2.4 cv=QbNrf8bv c=1 sm=1 tr=0 ts=695b4715 cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=eJTnxkHzwNBm_rMR:21 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VnNF1IyMAAAA:8 a=caZseG3hBst_sJegXH8A:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: RskkyemhhUEd73pbA-vb9yGNvqeZdO6W X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTA1MDA0MiBTYWx0ZWRfX8hOBYIOOnh/V C4stzHRwORJJd5zJtzO8uFnV8ovG9rA5GlqibVBZi/ywsx8rSgQYEoGxEYRLSYT6zzrJh2jW1pD Q/+GGPTBAdQU2Ibi2D5MbcmnHtgcdc+MKzYwAmG+FgbLZSSc08OHbGLhLutTMYTIzFihZ/etSdI ytR0ZVNCYyolH9U2F5daxaAvQIiycEtlZBF4UC3v0Rj/ckw+RBZFtnCvj5NE0mTB/0yCcr0wYN5 jYvo5B7uRrppVlBBiC7hJoTAIlUMOzjvo8UYLIWKDnOBfm4iZirE+PPG8iiJapsvpkTGoCh5E8y yLPyRtrJJ06909K8RzqGT2xtiaoA+1LxTE/1AkAE05S6JCYKYDmVpzhs9ijaeh0ZTetcysg6Yux m8rafjLm+hoik/+oG2w3ncdtjwAMasFblWUTq5GbBYFz36C40QUQ/eCMtsUGlak/sEfPDVRjhqe qb1rDJWCQ8aScMp+KRg== X-Proofpoint-GUID: RskkyemhhUEd73pbA-vb9yGNvqeZdO6W X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2026-01-04_07,2025-12-31_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 bulkscore=0 suspectscore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 impostorscore=0 phishscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2512120000 definitions=main-2601050042 On 1/5/26 9:22 AM, K Prateek Nayak wrote: > Hello Shrikanth, > > On 1/2/2026 6:17 PM, Shrikanth Hegde wrote: >> These days most of the system have multi cores. The likelyhood of >> at least one or more CPUs in nohz (idle state) is higher. >> So move likely to unlikely. >> >> Allow stats balancing to complete when there are no nr_cpus as the check >> happens later. This may do an additional stats based load balancing >> which would reset has_blocked_load. Code also looks saner by removing >> that uncharactiristic return in between. >> >> Signed-off-by: Shrikanth Hegde >> --- >> kernel/sched/fair.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index cd1c78d2c272..5ceb9126d441 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -12456,10 +12456,10 @@ static void nohz_balancer_kick(struct rq *rq) >> >> /* >> * None are in tickless mode and hence no need for NOHZ idle load >> - * balancing: >> + * balancing, do stats update if its due >> */ >> - if (likely(!atomic_read(&nohz.nr_cpus))) >> - return; >> + if (unlikely(!atomic_read(&nohz.nohz_balancer_kick))) >> + goto out; Did something got edited here? > Since we are sure that "nohz.nr_cpus" is 0, there is a good chance > find_new_ilb() in kick_ilb() will not find any CPU to run balance on, so > why not just retain that return? > > The "flags" can only be set to (NOHZ_NEXT_KICK | NOHZ_STATS_KICK) on > this path and kick_ilb() will simply return early without updating > "nohz.next_balance" when it doesn't see NOHZ_BALANCE_KICK and fails to > find any CPU. Might as well keep the early return. > The only reason why flags would be set is, if nohz.has_blocked_load is set and time is after next_blocked. In that case, doing a stats based balance will make nohz.has_blocked_load=0 and subsequent invocations flags =0 and no load balance will happen if nr_cpus stays 0. However, if we just, has_blocked_load might remains stale value. Isn't that the case?