On 14.10.25 10:32, zhaoyang.huang wrote:
From: Zhaoyang Huang <[email protected]>
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
