Re: [PATCH 1/2] mm: call back alloc_pages_bulk_list since it is useful
From: David Hildenbrand
Date: Wed Oct 15 2025 - 08:16:59 EST
On 14.10.25 10:32, zhaoyang.huang wrote:
From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
Probably the subject should be "mm: reintroduce alloc_pages_bulk_list()"
commit c8b979530f27 ("mm: alloc_pages_bulk_noprof: drop page_list
argument") drops alloc_pages_bulk_list. This commit would like to call back
it since it is proved to be helpful to the drivers which allocate a bulk of
pages(see patch of 2 in this series ).
"Let's reintroduce it so we can us for bulk allocation in the context of XXX next."
I do notice that Matthew's comment of the time cost of iterating a list.
However, I also observed in our test that the extra page_array's allocation
could be more expensive than cpu iteration when direct reclaiming happens
when ram is low[1]. IMHO, could we leave the API here to have the users
choose between the array or list according to their scenarios.
I'd prefer if we avoid reintroducing this interface.
How many pages are you intending to allocate? Wouldn't a smaller array on the stack be sufficient?
--
Cheers
David / dhildenb