[PATCH] MM: clarify effort used in alloc_pages_bulk_*()

[PATCH] MM: clarify effort used in alloc_pages_bulk_*()

[NeilBrown]

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@suse.de>
---
 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

Re: [PATCH] MM: clarify effort used in alloc_pages_bulk_*()

[Mel Gorman]

On Mon, Aug 30, 2021 at 08:28:15AM +1000, NeilBrown wrote:
> 
> 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@suse.de>

Acked-by: Mel Gorman <mgorman@suse.com>

-- 
Mel Gorman
SUSE Labs