On 05.08.25 15:36, Linus Torvalds wrote:
On Tue, 5 Aug 2025 at 16:26, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
David, there is another alternative to prevent this, simple though a
bit wasteful, just allocate a bit bigger to ensure the allocation
doesn't end on an exact PAGE_SIZE boundary?
So I don't mind adding a check for "page_section()", because at least
that makes sense.
But yes, it would also probably be a good idea to try to minimize
SPARSEMEM without VMEMMAP. I'd love to get rid of it entirely, of
course, but even if that isn't possible, I'd *really* just like people
to try to make sure that it's neve ra valid thing to try to combine
memory across different sections.
David mentioned the 1GB hugepage folios, and I really thought that
even *those* were all in one section. They *should* be.
The memory section size on x86 is always 128 MiB. Even with SPARSEMEM.
There are weird interactions between memory section size and memory
hotplug / DAX, so we try to keep it small'ish.
It's more that we don't care that much about memory section size with
SPARSEMEM because nth_page() and everything around that is just plain
simple.
Do we have any relevant architectures that still do SPARSEMEM without
VMEMMAP? Because if it's purely some "legacy architecture" thing (ie
x86-32), how about just saying "no 1GB hugepages for you".
arch/arm64/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/loongarch/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/powerpc/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/riscv/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE if 64BIT
arch/s390/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/sparc/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE
arch/x86/Kconfig: select SPARSEMEM_VMEMMAP_ENABLE if X86_64
But SPARSEMEM_VMEMMAP is still user-selectable.
I would assume SPARSEMEM_VMEMMAP_ENABLE support would cover most hugetlb
+ dax users indeed, at least when it comes to gigantic folios.
Would have to figure out why someone would want to disable it (limited
vspace? but that should also not really be a problem on 64bit I think).
--
Cheers,
David / dhildenb
