On 26.08.25 15:03, Alexandru Elisei wrote:
Hi David,
On Tue, Aug 26, 2025 at 01:04:33PM +0200, David Hildenbrand wrote:
..
Just so I can better understand the problem being fixed, I guess you can have
two consecutive pfns with non-consecutive associated struct page if you have two
adjacent memory sections spanning the same physical memory region, is that
correct?
Exactly. Essentially on SPARSEMEM without SPARSEMEM_VMEMMAP it is not
guaranteed that
pfn_to_page(pfn + 1) == pfn_to_page(pfn) + 1
when we cross memory section boundaries.
It can be the case for early boot memory if we allocated consecutive areas
from memblock when allocating the memmap (struct pages) per memory section,
but it's not guaranteed.
Thank you for the explanation, but I'm a bit confused by the last paragraph. I
think what you're saying is that we can also have the reverse problem, where
consecutive struct page * represent non-consecutive pfns, because memmap
allocations happened to return consecutive virtual addresses, is that right?
Exactly, that's something we have to deal with elsewhere [1]. For this
code, it's not a problem because we always allocate a contiguous PFN range.
If that's correct, I don't think that's the case for CMA, which deals out
contiguous physical memory. Or were you just trying to explain the other side of
the problem, and I'm just overthinking it?
The latter :)
[1] https://lkml.kernel.org/r/20250814064714.56485-2-lizhe.67@xxxxxxxxxxxxx
--
Cheers
David / dhildenb
