(+ Marc) On Fri, 4 Dec 2020 at 12:14, Will Deacon <w...@kernel.org> 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 <liwei...@huawei.com> > > Signed-off-by: Baopeng Feng <fengbaope...@hisilicon.com> > > Signed-off-by: Xia Qing <saberlily....@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? > > 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. >
Does this mean we will run into problems with the GICv3 ITS LPI tables again if we are forced to reduce MAX_ORDER to fit inside SECTION_SIZE_BITS?