| Message ID | 163027609524.7591.4987241695872857175@noble.neil.brown.name (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | MM: clarify effort used in alloc_pages_bulk_*() | expand |
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>
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; }
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(-)