Messages in this thread Patch in this message | | | Date | Fri, 4 Dec 2020 13:44:00 +0200 | From | Mike Rapoport <> | Subject | Re: [PATCH] arm64: mm: decrease the section size to reduce the memory reserved for the page map |
| |
On Fri, Dec 04, 2020 at 11:13:47AM +0000, Will Deacon wrote: > On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote: > > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP > > do not free the reserved memory for the page map, decrease the section > > size can reduce the waste of reserved memory. > > > > Signed-off-by: Wei Li <liwei213@huawei.com> > > Signed-off-by: Baopeng Feng <fengbaopeng2@hisilicon.com> > > Signed-off-by: Xia Qing <saberlily.xia@hisilicon.com> > > --- > > arch/arm64/include/asm/sparsemem.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h > > index 1f43fcc79738..8963bd3def28 100644 > > --- a/arch/arm64/include/asm/sparsemem.h > > +++ b/arch/arm64/include/asm/sparsemem.h > > @@ -7,7 +7,7 @@ > > > > #ifdef CONFIG_SPARSEMEM > > #define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS > > -#define SECTION_SIZE_BITS 30 > > +#define SECTION_SIZE_BITS 27 > > We chose '30' to avoid running out of bits in the page flags. What changed?
I think that for 64-bit there are still plenty of free bits. I didn't check now, but when I played with SPARSEMEM on m68k there were 8 bits for section out of 32.
> With this patch, I can trigger: > > ./include/linux/mmzone.h:1170:2: error: Allocator MAX_ORDER exceeds SECTION_SIZE > #error Allocator MAX_ORDER exceeds SECTION_SIZE > > if I bump up NR_CPUS and NODES_SHIFT.
I don't think it's related to NR_CPUS and NODES_SHIFT. This seems rather 64K pages that cause this.
Not that is shouldn't be addressed.
> Will
-- Sincerely yours, Mike.
| |