From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (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 01DC62D7387 for ; Tue, 23 Dec 2025 08:04:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766477046; cv=none; b=urLjFP1Su9Sw0ehscObTAty1fxE6txlIC5S1aAI1InsH5h37fbBfuWTHJenV3MGRpXk7UqrEE5OS9yhi3A6mtr6813xUPKAxSd4m3IOKTPaojnQaWo2W+g+RgWdGWwzMDHEXBJv7LrDXRKj74saX8++2Ejd8V3s8VrGVcVB9nz8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766477046; c=relaxed/simple; bh=zsbtX7gop3mWzjwgGzSIw0BgYDdA1HovD1Za+aBimDo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lGRSoassQgQ9xcWudTAp0Frp31/w01E48pR8nP+xnB4Ji9XmQ0P3uLWpTrqvH1ryjkriXeGwLhRcm+ETvcpKNDVAw8BP9yrZMWYaSygb9+j5HBP6CpYOx8HcduNlUy6Fz0O8gvSLXNhwXUEx9e6j8LOeeync7vKJQXr9v4oQLYs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=BAzCj+R8; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="BAzCj+R8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1766477046; x=1798013046; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=zsbtX7gop3mWzjwgGzSIw0BgYDdA1HovD1Za+aBimDo=; b=BAzCj+R8sIOQxQgDPPNWAkjX6X3ltaS8y8whBM7oic66DOs/UAbyq3xf ztWIwV4PkAZdvjNHQyPg8vvczGkA/U6cOV2nj/ZvU5gn6aEkWnrzXfh0v sUgAt9CdCKEWIVvKxsXotviyWeYU8ycGUaz5XyUOCo5zU1B2B1JdcwnE7 1BzpHwtvJN1enb+hsoROpvxw4LGn0KnMOHBC3+JAepHbbuziJKlxKLdyj NuTzrHd3odKPvoiT/Vtk/CBUXLy/PES+SE2nS4SXV9wS4Q/HoU+GPnIHd QgM1tRhQ9VjikVFUTI/S5a/WC1RsoptSfaWyLIRI4bJTF73B5BGDiTq7W A==; X-CSE-ConnectionGUID: 3xcf4zkaTNO/CfVqglG12Q== X-CSE-MsgGUID: Q59br+chQYqKC0qq9x8i2w== X-IronPort-AV: E=McAfee;i="6800,10657,11650"; a="79444442" X-IronPort-AV: E=Sophos;i="6.21,170,1763452800"; d="scan'208";a="79444442" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Dec 2025 00:04:05 -0800 X-CSE-ConnectionGUID: osNu/FDsQmeyIJrUVhcgFQ== X-CSE-MsgGUID: 2W1eMTM+TTWIk9dhWLlnFw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,170,1763452800"; d="scan'208";a="199754180" Received: from unknown (HELO [10.238.3.27]) ([10.238.3.27]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Dec 2025 00:04:00 -0800 Message-ID: <8445130b-7672-45a7-9c9e-512aa6029a56@intel.com> Date: Tue, 23 Dec 2025 16:03:23 +0800 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: Shrikanth Hegde 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> <7297e5e6-ae5a-42dc-8495-fddbb87ddf87@intel.com> <917c1771-5249-4c10-9ecf-699cdd323cd9@linux.ibm.com> Content-Language: en-US From: "Guo, Wangyang" In-Reply-To: <917c1771-5249-4c10-9ecf-699cdd323cd9@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/23/2025 3:27 PM, Shrikanth Hegde wrote: >>> >>> 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. >> >> The data follow by nohz is implicit and determined by compiler. >> For example, this is the layout from /proc/kallsyms in my machine: >> ffffffff88600d40 b nohz >> ffffffff88600d68 B arch_needs_tick_broadcast >> ffffffff88600d6c b __key.264 >> ffffffff88600d6c b __key.265 >> ffffffff88600d70 b dl_generation >> ffffffff88600d78 b sched_clock_irqtime >> >> What we can do is placing read-mostly `idle_cpus_mask` pointer in a >> new cacheline, so data followed by nohz would not be affected by nr_cpus. >> > > That's a concern. If it is compiler dependent, then sometime it helps, > sometime it wont. This patch wants to make it compiler independent. Sometimes it maybe sched_clock_irqtime, sometimes, it maybe baba_vars. Changing on nohz makes sure it would not affect others, no matter whatever data followed. > It should done other way around rather than changing the nohz. > If there is structure which has a lot of read/updates, it should go into > its > own cacheline rather. > > i.e in your case sched_clock_irqtime should go into its own cacheline. If that is preferred in kernel, I can resubmit the patch which only requires alignment on sched_clock_irqtime. > --- > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c > index 4f97896887ec..29f9438f9f03 100644 > --- a/kernel/sched/cputime.c > +++ b/kernel/sched/cputime.c > @@ -25,7 +25,7 @@ >   */ >  DEFINE_PER_CPU(struct irqtime, cpu_irqtime); > > -int sched_clock_irqtime; > +int sched_clock_irqtime __cacheline_aligned; > >  void enable_sched_clock_irqtime(void) >  { > > BR Wangyang