On 2024/1/3 0:11, David Hildenbrand wrote:
On 02.01.24 07:53, Kefeng Wang wrote:
On 2023/12/29 19:15, David Hildenbrand wrote:
On 29.12.23 09:49, Matthew Wilcox wrote:
On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote:
The clear and copy of huge gigantic page has converted to use
nth_page()
to handle the possible discontinuous struct page(SPARSEMEM without
VMEMMAP),
but not change for the non-gigantic part, fix it too.
Can there be discontiguities within a non-gigantic huge page? My
impression was that you can't have a discontiguity at such a small
boundary.
No, we can't. MAX_ORDER allocations from the buddy always completely fit
into a memory section.
On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section,
right?
I recall the mem sections are always at least 128 MiB on arm64.
Note that anything > MAX_ORDER is called a "gigantic huge page" in
hugetlb code.
Yes, we already check MAX_ORDER, please ignore this one, thanks.
