On Mon, 7 Dec 2020 at 10:42, Mike Rapoport [off-list ref] wrote:

On Mon, Dec 07, 2020 at 09:35:06AM +0000, Marc Zyngier wrote:

quoted

On 2020-12-07 09:09, Ard Biesheuvel wrote:

quoted

(+ Marc)

On Fri, 4 Dec 2020 at 12:14, Will Deacon [off-list ref] wrote:

quoted

On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote:

quoted

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 <redacted>
Signed-off-by: Baopeng Feng <redacted>
Signed-off-by: Xia Qing <redacted>
---
 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?

Most probably. We are already massively constraint on platforms
such as TX1, and dividing the max allocatable range by 8 isn't
going to make it work any better...

I don't think MAX_ORDER should shrink. Even if SECTION_SIZE_BITS is
reduced it should accomodate the existing MAX_ORDER.

My two pennies.

But include/linux/mmzone.h:1170 has this:

#if (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS
#error Allocator MAX_ORDER exceeds SECTION_SIZE
#endif

and Will managed to trigger it after applying this patch.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel