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 84A1D2367CF for ; Sun, 21 Dec 2025 13:05:32 +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=1766322334; cv=none; b=ZcP/aLN02M8vRPFmWjZc2YZaV+3H4ZD5s8ZncZLL0SL+BmY64EhxVIr22ro/8mh09vEkefkcX0UtLgf4zgdtaCRPJtBqxGHCSv+HjgW3hL21hOfFAJ4kgdHn6ZkJ31SZtOpmmf9bP325h75k42CzIhofV7DDGNKKTIJSJ1+q5SE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766322334; c=relaxed/simple; bh=YAfsRgbiUa4AWDtmZLFy4jUnF2zzx66FqzMt/Y8iowo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=heRHOoP3X0oogQo1mzv+O6GxmHU3dY4CUWrFXW6348j4vXFxTnPFecgmtfT5fDQUW6wRl+eQ9mv4qkX57k1mFVpY2O2P10769M4I8LD4b88c/76ZvMUqRE+CvKXxEdTZ/u/7xGmtArOvkmT0Z+93jw2wfph1XVfbSGz1BWoCLdM= 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=owHy4s7/; 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="owHy4s7/" 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 5BK9use0006558; Sun, 21 Dec 2025 13:05:11 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=dFTj/O EjR6Rbm9CrReD/wZANi6p1R0HRnD50/h1vTD4=; b=owHy4s7/YwcNsazVPLGDRk QeEeVFuT/bAgeVQ7uwKIObOBKJ0ieNWE58XakBkUPS6yPdbS9kv8EdA7ywQZH43S oBRLEsIjhNnntaVu3omfSLme8fotMKbzy4LxWkWeAclcM1b/cmG7WjJBEaq0CVF+ LQU8Dv7UWz7NQHDDBuyJXXB2gg4KeeK24eDEDuFgTjTlbyKPHXXowlgrdKuJuGqJ AfzAtwcEnz2FZZ495v/px1HDycPYSTOMZf7gaG/JbBA45BhqmlSF+g8T47RE7LUG J4ZIOtvf3ZH5ZHGExbXsY+4N3RbpBferTFQ4OYYcbd6B24JQ7ZzgcK9dpNjIQ57w == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4b5j7dv6fh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Dec 2025 13:05:10 +0000 (GMT) Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5BLD5AeF013192; Sun, 21 Dec 2025 13:05:10 GMT 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 4b5j7dv6fg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Dec 2025 13:05:10 +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 5BL97kvx032273; Sun, 21 Dec 2025 13:05:09 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4b68u0se6f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Dec 2025 13:05:09 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5BLD57en35258842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 21 Dec 2025 13:05:07 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A739420043; Sun, 21 Dec 2025 13:05:07 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A879720040; Sun, 21 Dec 2025 13:05:04 +0000 (GMT) Received: from [9.39.21.201] (unknown [9.39.21.201]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Sun, 21 Dec 2025 13:05:04 +0000 (GMT) Message-ID: Date: Sun, 21 Dec 2025 18:35:03 +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] sched/fair: Avoid false sharing in nohz struct To: Wangyang Guo Cc: linux-kernel@vger.kernel.org, Benjamin Lei , Tim Chen , Tianyou Li , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider References: <20251211055612.4071266-1-wangyang.guo@intel.com> Content-Language: en-US From: Shrikanth Hegde In-Reply-To: <20251211055612.4071266-1-wangyang.guo@intel.com> 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=G8YR0tk5 c=1 sm=1 tr=0 ts=6947f086 cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=IkcTkHD0fZMA:10 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=pGLkceISAAAA:8 a=VnNF1IyMAAAA:8 a=QyXUC8HyAAAA:8 a=8QUfX2tkgIlFy6zZSkUA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-ORIG-GUID: uNT691WTJDLxmmGhUB9Gz1U8SxleZV20 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjIxMDExOSBTYWx0ZWRfX/fWZue2aRgLy PkzJnl7PHW5vreWI+u2CLS9DSckoKQ5d0ESTaw2eSkU26+k886US2D8q2YIvwJp23IFTaFoZ7Rl 8+lFcIQvIaeWcGXFBZIbFQavky4yPg2MMJtnw/eARKhkP95XcmOQsLztA7v17pTm7O/ALavspie Ukcj3fOc8iktpzhHVY51HEsPkRqAz+tVHnnCp/TZ008eJjN2rcaeLeR1DRyXiocT7Sh3Ft9d/27 2kK9Z1HVx2ZbYTQ+bpNYna3+jNmqmOcMg45kOh46p/TOXxCRmjgYgbpDLkZ16tCa8N3wo+BacYl XmLr1T7hF5PcymYL8s0LktYpLtkorTB4FKMOdtc3QqKZc0PxIU6XfeqxNO3l8vNtDo/apgVLFuw iexcQojB47Z/ppLKtaBbviHyxQ5WU9QoaOR08o6nwdBDv1L0AwviyGPwby/blRA56+7d8XpXRpY OQHrBtPQ6jviRlDtO6w== X-Proofpoint-GUID: I5Mz14gkUSzYOGatfsdnnZVvYQibX3EH 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-12-21_03,2025-12-19_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 clxscore=1011 adultscore=0 spamscore=0 malwarescore=0 impostorscore=0 phishscore=0 suspectscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2512120000 definitions=main-2512210119 Hi Wangyang, On 12/11/25 11:26 AM, Wangyang Guo wrote: > There are two potential false sharing issue in nohz struct: > 1. idle_cpus_mask is a read-mostly field, but share the same cacheline > with frequently updated nr_cpus. Updates to idle_cpus_mask is not same cacheline. it is updated alongside nr_cpus. with CPUMASK_OFFSTACK=y, idle_cpus_mask is a pointer to the actual mask. Updates to it happen in another cacheline. with CPUMASK_OFFSTACK=n, idle_cpus_mask is on the stack and its length depends on NR_CPUS. typical value being 512/2048/8192 it can span a few cachelines. So updates to it likely in different cacheline compared to nr_cpus. see https://lore.kernel.org/all/aS6bK4ad-wO2fsoo@gmail.com/ Likely in your case, nr_cpus updates are the costly ones. Try below and see if it helps to fix your issue too. https://lore.kernel.org/all/20251201183146.74443-1-sshegde@linux.ibm.com/ I Should send out new version soon. > 2. Data followed by nohz still share the same cacheline and has > potential false sharing issue. > How does your patch handle this? I don't see any other struct apart from nohz being changed. > This patch tries to resolve the above two problems by isolating the > frequently updated fields in a single cacheline. > > Reported-by: Benjamin Lei > Reviewed-by: Tim Chen > Reviewed-by: Tianyou Li > Signed-off-by: Wangyang Guo > --- > kernel/sched/fair.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 5b752324270b..bcc2766b7986 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -7193,13 +7193,14 @@ static DEFINE_PER_CPU(cpumask_var_t, should_we_balance_tmpmask); > #ifdef CONFIG_NO_HZ_COMMON > > static struct { > - cpumask_var_t idle_cpus_mask; > - atomic_t nr_cpus; > + /* Isolate frequently updated fields in a cacheline to avoid false sharing issue. */ > + atomic_t nr_cpus ____cacheline_aligned; > 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 */ > unsigned long next_blocked; /* Next update of blocked load in jiffies */ > -} nohz ____cacheline_aligned; > + cpumask_var_t idle_cpus_mask ____cacheline_aligned; > +} nohz; > This can cause a lot of space wastage. for exp: powerpc has 128 byte cacheline.