linux-kernel - Re: [RFC PATCH v2] Introduce Hierarchical Per-CPU Counters

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <077bfec0-c918-48b1-b133-36b4bba5d66a@paulmck-laptop>
Date: Tue, 8 Apr 2025 14:46:53 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Sweet Tea Dorminy <sweettea@...gle.com>,
	Mateusz Guzik <mjguzik@...il.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>,
	Martin Liu <liumartin@...gle.com>,
	David Rientjes <rientjes@...gle.com>, christian.koenig@....com,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Johannes Weiner <hannes@...xchg.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Christian Brauner <brauner@...nel.org>,
	Wei Yang <richard.weiyang@...il.com>,
	David Hildenbrand <david@...hat.com>,
	Miaohe Lin <linmiaohe@...wei.com>,
	Al Viro <viro@...iv.linux.org.uk>, linux-mm@...ck.org,
	linux-trace-kernel@...r.kernel.org, Yu Zhao <yuzhao@...gle.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Matthew Wilcox <willy@...radead.org>
Subject: Re: [RFC PATCH v2] Introduce Hierarchical Per-CPU Counters

On Tue, Apr 08, 2025 at 02:21:59PM -0700, Christoph Lameter (Ampere) wrote:
> On Tue, 8 Apr 2025, Paul E. McKenney wrote:
> 
> > RCU handles this by iterating from zero to nr_cpu_ids, which is set during
> > early boot.  It also builds its tree-shaped data structures during early
> > boot based on nr_cpu_ids.
> 
> nr_cpu_ids is better but there are funky things like the default bios of a
> major server vendor indicating 256 or so possible cpus although only 2
> were installed. Thus nr_cpu_id is 256. Presumably some hardware
> configurations can support onlining 256 cpus....

Indeed there are.  So some portions of RCU build for nr_cpu_ids but
activate portions of the data structures (e.g., spawn kthreads) only
for those CPUs that actually come online at least once.

But should we really be optimizing to that degree for that sort of
breakage?  Just extra data structure, who cares?

Yes, I do understand that the vendor in question, whoever it is, would
not consider their default BIOS to be broken.  They are welcome to
their opinion.  ;-)

							Thanx, Paul