linux-kernel - Re: [PATCH] sched/fair: Avoid false sharing in nohz struct

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <F272503E-9E67-411B-B8E6-1B31D954FC92@os.amperecomputing.com>
Date: Fri, 19 Dec 2025 01:38:03 +0000
From: Shubhang Kaushik Prasanna Kumar <shkaushik@...erecomputing.com>
To: "wangyang.guo@...el.com" <wangyang.guo@...el.com>
CC: "benjamin.lei@...el.com" <benjamin.lei@...el.com>, "bsegall@...gle.com"
	<bsegall@...gle.com>, "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
	"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mgorman@...e.de" <mgorman@...e.de>, "mingo@...hat.com" <mingo@...hat.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "rostedt@...dmis.org"
	<rostedt@...dmis.org>, "tianyou.li@...el.com" <tianyou.li@...el.com>,
	"tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"vschneid@...hat.com" <vschneid@...hat.com>
Subject: Re: [PATCH] sched/fair: Avoid false sharing in nohz struct

Hi Wangyang Guo,

While the intuition behind isolating the `nr_cpus` counter seems correct, could you please justify the added padding ? As this is a high contention path in the scheduler, we shouldn't be inflating global structures with padding on logic alone. I’d like to see some benchmarking such as `perf c2c` results from a multi-core system proving the `false sharing` scenario as a measurable bottleneck.

I am also concerned about the internal layout. By sandwiching the timer fields between two `__cacheline_aligned` boundaries, we might just be shifting the contention rather than fixing it.  See to it that fields like `next_balance` aren't being squeezed into a new conflict zone. Would like to review the benchmark data and the struct layout before we move forward.

Thanks,
Shubhang Kaushik