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 <[email protected]> > > Signed-off-by: Baopeng Feng <[email protected]> > > Signed-off-by: Xia Qing <[email protected]> > > --- > > 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.
