On 05.08.25 14:56, Jason Gunthorpe wrote:
On Tue, Aug 05, 2025 at 02:41:38PM +0200, David Hildenbrand wrote:
On 05.08.25 14:38, Jason Gunthorpe wrote:
On Tue, Aug 05, 2025 at 02:07:49PM +0200, David Hildenbrand wrote:
I don't see an easy way to guarantee that. E.g., populate_section_memmap
really just does a kvmalloc_node() and
__populate_section_memmap()->memmap_alloc() a memblock_alloc().
Well, it is really easy, if you do the kvmalloc_node and you get the
single unwanted struct page value, then call it again and free the
first one. The second call is guarenteed to not return the unwanted
value because the first call has it allocated.
So you want to walk all existing sections to check that? :)
We don't need to walk, compute the page-1 and carefully run that
through page_to_pfn algorithm.
You have to test if first_page-1 and last_page+1 are used as the memmap
for another section.
So yeah, it could be done by some page_to_pfn + pfn_to_page trickery I
think.
Not that I would like that "allocate until you find something that
works" approach.
That's the kind of approach I would describe with the words Linus used.
Its some small boot time nastyness, we do this all the time messing up
the slow path so the fast paths can be simple
nth_page won't go away. If it would go away, I would be sold on almost
any idea. nth_page is the real problem.
So I don't like the idea of micro-optimizing num_pages_contiguous() by
adding weird tweaks to the core for that.
--
Cheers,
David / dhildenb
