linux-kernel - Re: [PATCH] mm/fake-numa: per-phys node fake size

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

Message-ID: <Zvuhmv7exzL8sMoW@kernel.org>
Date: Tue, 1 Oct 2024 10:15:38 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Bruno Faccini <bfaccini@...dia.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	Zi Yan <ziy@...dia.com>, Timur Tabi <ttabi@...dia.com>,
	John Hubbard <jhubbard@...dia.com>
Subject: Re: [PATCH] mm/fake-numa: per-phys node fake size

On Sun, Sep 29, 2024 at 03:43:50PM +0000, Bruno Faccini wrote:
> 
> On 25/09/2024 11:32, "Mike Rapoport" <rppt@...nel.org <mailto:rppt@...nel.org>> wrote:
> > On Tue, Sep 24, 2024 at 03:27:52PM +0000, Bruno Faccini wrote:
> > > On 24/09/2024 12:43, "Mike Rapoport" <rppt@...nel.org <mailto:rppt@...nel.org>> wrote:
> >
> > > I don't think that fake=N allocation method is intended to get fake nodes
> > > with equal size, but to get this exact number of nodes. This is why I
> > > think we should use a per-phys node size for the fake nodes it will host.
> >
> > IMO your change adds to much complexity for a feature that by definition
> > should be used only for debugging.
> 
> Well it is only executed once during boot, and as you said for debugging,
> so I believe when the boot speed is not a requirement.  And my testing on
> our fat Numa nodes did not show a real difference.

I meant code complexity, not the execution complexity.
 
> > Also, there is a variation numa=fake=<N>U of numa=fake parameter that
> > divides each node into N emulated nodes.
> 
> Right, but both methods should work as expected, is'nt it ?
> And one allocates emulated nodes interleaved on physical nodes when the
> second is doing allocation serially.

I think we can just bail out with an error if we fail to create the
requested emulated nodes.

-- 
Sincerely yours,
Mike.