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]
Date:   Wed, 25 May 2022 20:12:07 +0300
From:   Mike Rapoport <rppt@...nel.org>
To:     Darren Hart <darren@...amperecomputing.com>
Cc:     "Zhouguanghui (OS Kernel)" <zhouguanghui1@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "xuqiang (M)" <xuqiang36@...wei.com>
Subject: Re: [PATCH] memblock: config the number of init memblock regions

On Wed, May 25, 2022 at 09:44:56AM -0700, Darren Hart wrote:
> On Thu, May 12, 2022 at 09:28:42AM +0300, Mike Rapoport wrote:
> > On Thu, May 12, 2022 at 02:46:25AM +0000, Zhouguanghui (OS Kernel) wrote:
> > > 在 2022/5/11 14:03, Mike Rapoport 写道:
> > > > On Tue, May 10, 2022 at 06:55:23PM -0700, Andrew Morton wrote:
> > > >>
> > > >> Can we simply increase INIT_MEMBLOCK_REGIONS to 1024 and avoid the
> > > >> config option?  It appears that the overhead from this would be 60kB or
> > > >> so.
> > > > 
> > > > 60k is not big, but using 1024 entries array for 2-4 memory banks on
> > > > systems that don't report that fragmented memory map is really a waste.
> > > > 
> > > > We can make this per platform opt-in, like INIT_MEMBLOCK_RESERVED_REGIONS ...
> > > 
> > > As I described above, is this a general scenario?
> > 
> > The EFI memory on arm64 is generally bad because of all those NOMAP
> > carveouts spread all over the place even in cases without memory faults. So
> > it would make sense to increase the number of memblock regions on arm64
> > when CONFIG_EFI=y.
> 
> This seems like a reasonable approach. I would prefer not to have to increase
> the default for EFI arm64 systems (and all that entails with coordinating with
> distros, etc.). The point below about other arch's not needing this is a good
> one too. This seems like a reasonable way make the defaults work everywhere
> while only paying the price on the systems that require it.
 
There's already v2 of this patch:

https://lore.kernel.org/all/20220517114309.10228-1-zhouguanghui1@huawei.com
  
> -- 
> Darren Hart
> Ampere Computing / OS and Kernel

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists