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 28F24221546 for ; Mon, 1 Dec 2025 18:32:36 +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=1764613958; cv=none; b=VgZtu8Lo6izE+HjkRUairW/XcydGWXG+Zz29Tafna8HIelH1TywX8UztH8Tu8YlEx3j/n2lWOyBpAIf1+ZGJ7sQvR9fmXOz7jAa7KYLUQYP7i63QcsR9Lqce2m0ybNXOhUH8BWSJUBv1T+2emva8G4KdGxU9dEOcV71UH3ntOIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764613958; c=relaxed/simple; bh=M1SKHSPJvgGgJzmcTGBqFKt+icqS15vyCviRqlibxsE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=XLWhK4c+Izvv6DawXCtE6jeVj11pLO8vfYY8TeeIA8h9s/PZ4vJUzBC+tJt+nMYV2+acRrPKXnBIsRAudbm0awGUvcoPRyKQC8AcZ9T8FK8rmQue+N7Z6OHsKL2J/DFCb9SgFHyx7SoAjVZTtPdeAPfPoZwBTIwPixXzhFM0PFk= 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=lCzeIB/P; 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="lCzeIB/P" Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5B1EY5BR025466; Mon, 1 Dec 2025 18:32:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:message-id:mime-version :subject:to; s=pp1; bh=X9xQG0zlTGX5EYPNmS9G6UTve7dlkpuLQJuhDuPHo jQ=; b=lCzeIB/Px2DUkdY8orssBlU3iAi0XhEfbFwRGl7gnLzbD0Tllc5e6MCPE 7HO/mDuWx/1hb0fHPYnbJ1yZPCHPo5Kuy8WTNwS1wrMoJmof8WuLj5pGBXaHj9+H Rzf4gS1bM6Z0Qz9A/1cqwMq4Zndx2yIsidd1ixV2vulJdfVNysfUpZO6bw3tVApK Fmpp0WvGscwcSJhTJ65H7tifkAQM6rKpOTpxSV/W1qfOCIgLBrZbwPgab4D30z5U rRSfV0AFfrqK7dh4XGko78Ki//ucM6q30xdRHLBZ2iiqFfRoz69aw7hXlkfs16Ub TAlODSv3p0RDWppRXTFD1tTnZnZmg== Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4aqrh6rvdk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Dec 2025 18:32:07 +0000 (GMT) Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5B1FvH2X008660; Mon, 1 Dec 2025 18:32:06 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4arc5mr2kh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Dec 2025 18:32:05 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5B1IW4ti43647348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 1 Dec 2025 18:32:04 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DD4202004B; Mon, 1 Dec 2025 18:32:03 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1EEFD20043; Mon, 1 Dec 2025 18:32:01 +0000 (GMT) Received: from li-7bb28a4c-2dab-11b2-a85c-887b5c60d769.ibm.com.com (unknown [9.124.221.183]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 1 Dec 2025 18:32:00 +0000 (GMT) From: Shrikanth Hegde To: mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, kprateek.nayak@amd.com Cc: sshegde@linux.ibm.com, dietmar.eggemann@arm.com, vschneid@redhat.com, rostedt@goodmis.org, tglx@linutronix.de, tim.c.chen@linux.intel.com Subject: [PATCH 0/4] sched/fair: improve nohz fields for large systems Date: Tue, 2 Dec 2025 00:01:42 +0530 Message-ID: <20251201183146.74443-1-sshegde@linux.ibm.com> X-Mailer: git-send-email 2.51.0 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-Authority-Analysis: v=2.4 cv=dK+rWeZb c=1 sm=1 tr=0 ts=692ddf27 cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=zd2uoN0lAAAA:8 a=8xEu12yW_nbflF4mC38A:9 X-Proofpoint-GUID: TQIpw5wFWT0YCJtq6ONnsJUXnICJTly7 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMTI5MDAyMCBTYWx0ZWRfX23oKmUpC8+DG Aps4IxKDKZt1hasHT93JsEgE1tGaF1X/qc07Yj6m+VaTfYRTgdopf2S2D1+ruKTa7LEHz1cSNcG uuZtir9QmMvz/u+wXWZAgf/I9xahlKXyYJ+jZlR4jVEJ5n7bRENXauxNTzFVl3MznO1KvH86rNn wrfEtRw/6IzLmR6xpVywzJHToWHu5/hoBDfB6Lxd9P25b+LumF77XvrHY8+lSJQRiG5/3n/ANHf SoQnSUlZCNoRnqyY01IfhhWiCQ46qFqTrnl4erVts1wauE3KL/acxtoMCw7hM+BcazP8MwBSe8H HYFv7YGvZTNEHSWI0okMY22C0wkG+aVxOEH4btEyC4Nm19T9coUdG1Wtz3UiBjqIoeKaaHudO5+ 9jK0BMXgEEkfkkLlyAGWk8LX23Brow== X-Proofpoint-ORIG-GUID: TQIpw5wFWT0YCJtq6ONnsJUXnICJTly7 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=2025-11-28_08,2025-11-27_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 bulkscore=0 adultscore=0 phishscore=0 impostorscore=0 spamscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2511290020 It was noted when running on large systems nohz.nr_cpus cacheline was bouncing quite often. There is atomic inc/dec and read happening on many CPUs at a time and it is possible for this line to bounce often. Gist of the series is to get rid of nr_cpus, instead use the cpumask which is always updated alongside with it. Functionally it should serve the same purpose. At worst, one might miss an idle load balance happening due to race. Looking at comments, it might happen even today. Other patches are minor ones. there are couple of time checks to bail out. Check the variables after the time checks to avoid cache references to it. There is a series which aims to solve contention by moving to LLC. https://lore.kernel.org/all/20250904041516.3046-1-kprateek.nayak@amd.com/ Maybe these bits are useful for that too. We could discuss further at LPC. Ran "hackbench 100 process 5000 loops" and collected perf cycles and selected top nohz functions. Benchmark numbers don't change by much. Will ask our performance team to do the numbers with the series. baseline: tip sched/core at 3eb593560146 1.01% [k] nohz_balance_exit_idle 0.31% [k] nohz_balancer_kick 0.05% [k] nohz_balance_enter_idle With series: 0.45% [k] nohz_balance_exit_idle 0.18% [k] nohz_balancer_kick 0.01% [k] nohz_balance_enter_idle Shrikanth Hegde (4): sched/fair: Move checking for nohz cpus after time check sched/fair: Change likelyhood of nohz nr_cpus check sched/fair: Check for blocked task after time check sched/fair: Remove atomic nr_cpus and use cpumask instead kernel/sched/fair.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) -- 2.43.0