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
| ||
|
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