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 039E61A0BD0 for ; Wed, 7 Jan 2026 06:52:19 +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=1767768741; cv=none; b=UDKFWv3IwyACn0On6LoouzAWCxX8bAsKxh8XfntsspQbB3jDxbP33r7cM6dasQJIe0d6VsIxq7yYyAzASgNNPSd1Nw83VIO1TXs63V9yOADosKPHhm0x2+fZx7heoyxOvqKAIpOfLvnGoJQaxnUFtnvh6rV0VR2l8koqHKURPI0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767768741; c=relaxed/simple; bh=O0MPzQIM7FZmo7jBJJl60qMcWsxf4SNYHpgs/eRKYV4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Ze6kS4nm9Koq/WpsbXZR3qDC3jlXokpR8OVUH5EXnd6JmxwHUMcrEjDQnPxiPQyDzybzTHVDEm16tx95mb0BC5W7nzzAs6XwIOHxxsDpKbqQ1r22rNZiVzhyPiDeC5fy+bVKuU/Qhqw1ITvHWq+5vDlPXaLNWWrqWaInYISy5Xs= 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=HRnY0rtw; 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="HRnY0rtw" Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 606HTlRA021441; Wed, 7 Jan 2026 06:51:50 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=iIa9r2A1L3cwMO7bRY8dAzB/4R1D9UyFOr0ZQuNKh 9A=; b=HRnY0rtwCK+C5hcg01tV1kF+yErNvkT9uOBoodZcWI4yWAn0LkoQpMKbS EQ+m58giPyNkRiSles6KQ1/MTlpgfqbPwjQRKBLT2K3jDAIdEbsEeIgiiQISauLl uG/LzHDUXqGOfCIoZD4e313x8fmpxYoAikbFCuSHWiQRzING08snSg9t09MeYupB z5GJW4xZe/4FXhhbcFu2uSgGxI3w4zVA9YqLcTqVyJSlcWM7b9AsZGkvwH0DFNvB jY7RmMH7rpMsfXX36NijNSQFbRaRfb/LqF3pH4YxIZ6rk/UhO/nr/A+CMtmaTH3v EetSyqDsuOiWMPb4k5KLgu321TSIg== 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 4betrtpe7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Jan 2026 06:51:49 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 6074gVq6012645; Wed, 7 Jan 2026 06:51:49 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4bffnjfdxt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Jan 2026 06:51:48 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 6076plnM31588710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Jan 2026 06:51:47 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2BD6620049; Wed, 7 Jan 2026 06:51:47 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7DF7B20040; Wed, 7 Jan 2026 06:51:44 +0000 (GMT) Received: from li-7bb28a4c-2dab-11b2-a85c-887b5c60d769.ibm.com.com (unknown [9.124.216.12]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 7 Jan 2026 06:51:44 +0000 (GMT) From: Shrikanth Hegde To: mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org Cc: sshegde@linux.ibm.com, kprateek.nayak@amd.com, 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 Subject: [PATCH v3 0/3] sched/fair: Improve nohz fields for large systems Date: Wed, 7 Jan 2026 12:21:22 +0530 Message-ID: <20260107065125.669668-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=aaJsXBot c=1 sm=1 tr=0 ts=695e0286 cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=vUbySO9Y5rIA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=RxYRiQ7SSsWcNr38ryEA:9 X-Proofpoint-GUID: 24PFyaYNXxSYZp5FSCoIMf2NqmoMWS42 X-Proofpoint-ORIG-GUID: 24PFyaYNXxSYZp5FSCoIMf2NqmoMWS42 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTA3MDA0OSBTYWx0ZWRfX6CSf+ngTnVls 0673gyizd3LCNy/c9TJUrLInln4U3lkUOHukRwI56DnGmF2bKA8HqFsGQ3+Z0G7qnescVx4eiiv ej5uUw7fJ1V7UGDr/OrFryFVRUCgd6Mo/qObVoo3xm++pQGcdn4XbphmfLVW3Qzh+ltPK9WKgua 8/xDGYX7YahKv4uYelQ14YzJV3AMEKvLgEUtxBu+lUItBuDil9eWD7IWQreOE88g9nA8DOlEnEp 7RW8+aY2gRQMBw1VKPxivs+zA2bDrZdwZdu2QVT7hSRRgYwe4om/oaqPyujmcGL4rvMVDqa1lP1 Csu3q8Jy++bb4K9sPDeHS0cYFD/T0DU75pWlJwcFuj3yKj4DxjQdN9whsvX/wOa4LuXIkD+Dfok FLRpZyKP0FsSCH1tTOSD3dj4bd3AtsT/PldoPL/ZQjr9IF3sXpZnOVOZQA8399VulDSxZ86srEL HV4rDg82h+VWvNeeVhw== 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-06_03,2026-01-06_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 phishscore=0 spamscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2512120000 definitions=main-2601070049 Running on large systems nohz.nr_cpus cacheline was seen as contended. There is atomic inc/dec and read happening on many CPUs at a time and it is possible for this line to bounce often. 1st and 2nd patch are minor ones. Looks like correct things to do. Not very important ones. 3rd patch: Main patch which 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. Rest of the fields aren't updated that often. So this line shouldn't bounce that often. Contention issue with nohz.idle_cpus_mask still remains. Mostly it is in separate cacheline than nohz. There are ongoing efforts to mitigate it. It is not addressed by this series. v2 -> v3: - Converted out to return when there are no CPU is in tickless mode since find_ilb_cpu returns anyway (K Prateek Nayak) v1 -> v2: - Dropped patch to check has_blocked based on time. - Detailed changelog for removing nr_cpus (Thanks to Ingo Molnar) v1: https://lore.kernel.org/all/20251201183146.74443-1-sshegde@linux.ibm.com/ v2: https://lore.kernel.org/all/20260102124744.360872-1-sshegde@linux.ibm.com/ Shrikanth Hegde (3): sched/fair: Move checking for nohz cpus after time check sched/fair: Change likelyhood of nohz.nr_cpus sched/fair: Remove nohz.nr_cpus and use weight of cpumask instead kernel/sched/fair.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) -- 2.47.3