On 14.10.25 10:32, zhaoyang.huang wrote:

From: Zhaoyang Huang zhaoyang.huang@unisoc.com

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?