The alloc_pages_bulk_*() interfaces do not make it clear what degree
of success can be expected.
The code appears to allocate at least one page with the same effort as
alloc_page() when used with the same GFP flags, and then to allocate any
more only opportunistically. So a caller should not *expect* to get a
full allocation, but should not be *surprised* by one either.
Add text to the comment clarifying this.
Also fix a bug. When alloc_pages_bulk_array() is called on an array
that is partially allocated, the level of effort to get a single page is
less than when the array was completely unallocated. This behaviour is
inconsistent, but now fixed.
Fixes: 0f87d9d30f21 ("mm/page_alloc: add an array-based interface to the bulk page allocator")
Signed-off-by: NeilBrown <neilb@xxxxxxx>
---
mm/page_alloc.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index eeb3a9cb36bb..083316c45964 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5206,6 +5206,11 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order,
* is the maximum number of pages that will be stored in the array.
*
* Returns the number of pages on the list or array.
+ *
+ * At least one page will be allocated if that is possible while
+ * remaining consistent with @gfp. Extra pages up to the requested
+ * total will be allocated opportunistically when doing so is
+ * significantly cheaper than having the caller repeat the request.
*/
unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
nodemask_t *nodemask, int nr_pages,
@@ -5307,7 +5312,7 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
pcp, pcp_list);
if (unlikely(!page)) {
/* Try and get at least one page */
- if (!nr_populated)
+ if (!nr_account)
goto failed_irq;
break;
}
--
2.32.0
