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 56ABB36D51B for ; Tue, 2 Dec 2025 05:29:54 +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=1764653397; cv=none; b=nawkh5zr838BVjGdDuppcRWKc5L9App8muYWsdIYxz4Q4z6kKG56aIgaIy5FcDkt9Su2V+PY4KBhc+qEycZy/O+OW1gaNrFPxF2KblT8Ue81MDYqLXlwHPSkEjMXYzTeSnIYBAdSfCHoZ9SJH0kUJMRrzbzJr01RRkE/bqSyogo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764653397; c=relaxed/simple; bh=4ixLfKSjtHILoV5F72L7RFbM8hGtV2vR0B8Ok8RDn00=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FLvbRo0shOjPmYetG97Ia1l3N+EJjRXeGCi97lX28CPylXQbsxTytbs4DBUeCn6ZYO5qzQlG4s2hijB7lBbfW3XdrOX76/5dAw9QDyDC+BiU5g4YbBuJlTjEKsUCFj7KL1IwU/cR32Wy21+7iy1+DokBwfdFJ8x43CVJ5zS6ROI= 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=NuSsm6sl; 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="NuSsm6sl" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5B1MRD0R001393; Tue, 2 Dec 2025 05:29:20 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=Fslczx Dp+aeL5SSG8jGKUnnxe7fOFqajPY8B186Sn2A=; b=NuSsm6slh1/1W9y2SRIMEq iZkPlPBw2g3ME5Kn388P2AMe+D5lPTaTbqJoVbhV0EETNvGUTc8/K1JYBXo3prH4 a8Mh2sU0FOKcgf6CLXWzXEsX/3wkoo8TcHRRJPYVZmYtEBJEC4qVd+CONBj0P9Q7 6NMn65jHlY0OM55+vI8Wm+wED7ElQc8l9b/LOo/B+TQEfWDYqlmTJ8irMPVkBTXC 9/TVsiHGuI2D6yttXWwN0EiUtss3ll71wx0XJ1q0E6qxslbgKnQQC6ZWHPdVf7zv xc8tVw6FCVdK7fy/zvPOuTGxDohVZtwdPH5TxJvIQj0JQh3flLxqZj7AswqhDKjQ == Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4aqq8uk1ae-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Dec 2025 05:29:19 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5B236F0h010292; Tue, 2 Dec 2025 05:29:19 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4arcnk2ecg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Dec 2025 05:29:18 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5B25THte51511774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 2 Dec 2025 05:29:17 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EBC4320043; Tue, 2 Dec 2025 05:29:16 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 58EF820040; Tue, 2 Dec 2025 05:29:14 +0000 (GMT) Received: from [9.124.220.253] (unknown [9.124.220.253]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 2 Dec 2025 05:29:14 +0000 (GMT) Message-ID: <15f8f8c6-df8f-4218-a650-eaa8f7581d67@linux.ibm.com> Date: Tue, 2 Dec 2025 10:59:13 +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 4/4] sched/fair: Remove atomic nr_cpus and use cpumask instead To: Ingo Molnar Cc: peterz@infradead.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, kprateek.nayak@amd.com, dietmar.eggemann@arm.com, vschneid@redhat.com, rostedt@goodmis.org, tglx@linutronix.de, tim.c.chen@linux.intel.com References: <20251201183146.74443-1-sshegde@linux.ibm.com> <20251201183146.74443-5-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-Proofpoint-ORIG-GUID: wqcFqzp_Ktm8cz6Z3PJJMktQBBwRwNWG X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMTI5MDAwOCBTYWx0ZWRfX0mx6MdiVJHef JiKjyRercMf/9NwJzN0AzUBNuFQhIFh+/jcy5yXMTn8I2PGmqmm7e8SlUloKJOPAZ2UDSlZ6nKR ZCbgJgnT44aCjbH9nIWZ4ogw8nWMbDg3cU5Fgh7itNfcJhr49f2rWDyLN0H9TOZ64uyvXUVEH6e c9+gizTTEL9WGN6VxssV1UyBZ+W7r8omlXqyOLBeNgM5178rCGtoAASV7Cfg76HSApnTaSJMXIo TyhnAyZCxsEgsBGUg6YvClzc0yqyiB1xDq8UYEYIhQdiAvnBWgihcF+NaRFgrvqJwryuCTh00Dp /eVK/C+U+R0woEsMzmli3AeA7w/dxsTLKc9to7awNV5Dmpx56EU0aqCLMTqndknD+xOHi3kYp3v 7lpw1fK+VWmpFzotEOANa+ZYTKEqUA== X-Authority-Analysis: v=2.4 cv=Scz6t/Ru c=1 sm=1 tr=0 ts=692e792f cx=c_pps a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17 a=IkcTkHD0fZMA:10 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=VnNF1IyMAAAA:8 a=lsZ_32iYXY0fMoN-KzsA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: wqcFqzp_Ktm8cz6Z3PJJMktQBBwRwNWG 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 phishscore=0 bulkscore=0 lowpriorityscore=0 adultscore=0 clxscore=1015 spamscore=0 impostorscore=0 priorityscore=1501 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2511290008 Hi Ingo, Thanks for taking a look at this. On 12/2/25 1:28 AM, Ingo Molnar wrote: > > * Shrikanth Hegde wrote: > >> nohz_balance_enter_idle: >> cpumask_set_cpu(cpu, nohz.idle_cpus_mask) >> atomic_inc(&nohz.nr_cpus) >> >> nohz_balance_exit_idle: >> cpumask_clear_cpu(rq->cpu, nohz.idle_cpus_mask) >> atomic_dec(&nohz.nr_cpus) >> >> kick_ilb: >> if (likely(!atomic_read(&nohz.nr_cpus))) >> return; >> >> So, idle_cpus_mask contains the same information. Instead of doing >> costly atomic in large systems, its better to check if cpumask is empty >> or not to make the same decision to trigger idle load balance. >> >> There might be race between cpumask_empty check and set of cpumask in >> the remote CPUs. In such case at next tick idle load balance will be >> triggered. Race of clearing the bit is not a concern, since _nohz_idle_balance >> checks if CPU is idle or not before doing the balance. >> >> cpumask_empty uses ffs. So should not be very costly. >> >> Signed-off-by: Shrikanth Hegde > >> static struct { >> cpumask_var_t idle_cpus_mask; >> - atomic_t nr_cpus; >> int has_blocked; /* Idle CPUS has blocked load */ >> int needs_update; /* Newly idle CPUs need their next_balance collated */ >> unsigned long next_balance; /* in jiffy units */ >> @@ -12450,7 +12449,7 @@ static void nohz_balancer_kick(struct rq *rq) >> * None are in tickless mode and hence no need for NOHZ idle load >> * balancing, do stats update if its due >> */ >> - if (unlikely(!atomic_read(&nohz.nr_cpus))) >> + if (unlikely(cpumask_empty(nohz.idle_cpus_mask))) >> goto out; > > So the thing is, if the goal is to avoid cacheline > bouncing, this won't fundamentally change the > situation: > >> rq->nohz_tick_stopped = 0; >> cpumask_clear_cpu(rq->cpu, nohz.idle_cpus_mask); >> - atomic_dec(&nohz.nr_cpus); > > nohz.idle_cpus_mask will be on a single 64-byte > cacheline even on 512 CPU systems, and the > cpumask_clear_cpu() and cpumask_set_cpu() calls will > dirty the cacheline and make it bounce with exactly the > same frequency as the atomic_inc/dec() of nohz.nr_cpus > does today. > > From the 0/4 boilerplate description: > > > 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. > > That the nr_cpus modification is an atomic op doesn't > change the situation much in terms of cacheline > bouncing, because the cacheline dirtying will still > cause comparable levels of bouncing on modern CPUs with > modern cache coherency protocols. > > If nr_cpus and nohz.nr_cpus are in separate cachelines, > then this patch might eliminate about half of the > bounces - but AFAICS they are right next to each other, > so unless it's off-stack cpumasks, they should be in > the same cacheline. Half of 'bad bouncing' is still > kinda 'bad bouncing'. :-) > You are right. If we have to get rid of cacheline bouncing then we need to fix nohz.idle_cpus_mask too. I forgot about CPUMASK_OFFSTACK. If CPUMASK_OFFSTACK=y, then both idle_cpus_mask and nr_cpus are in same cacheline Right?. That data in cover-letter is with =y. In that case, getting it to cpumask_empty will give minimal gains by remvong an additional atomic inc/dec operations. If CPUMASK_OFFSTACK=n, then they could be in different cacheline. In that case gains should be better. Very likely our performance team would have done with =n. IIRC, on powerpc, based on NR_CPU we change it. On x86 it chooses NR_CPUs. arm64/Kconfig: select CPUMASK_OFFSTACK if NR_CPUS > 256 powerpc/Kconfig: select CPUMASK_OFFSTACK if NR_CPUS >= 8192 x86/Kconfig: select CPUMASK_OFFSTACK x86/Kconfig: default 8192 if SMP && CPUMASK_OFFSTACK x86/Kconfig: default 512 if SMP && !CPUMASK_OFFSTACK In either case, if we think, nohz.nr_cpus == cpumask_weight(nohz.idle_cpus_mask) Since it is not a correctness stuff here, at worst we will lose a chance to do idle load balance. But at next tick we will do the idle balance. Looking at code it might happen even today, First we set/clear the mask and then we do inc/dec. So if mask was set, but inc hasn't happened, but read completed, then would lose a chance. (though very slim) > I'm not really objecting to the patch, because it would > reduce cacheline bouncing in the offstack-mask case, > but the explanation isn't very clear about these > details. > Let me re-write changelog. Also see a bit more into it. > Thanks, > > Ingo