[PATCH linux-next] mm/page_alloc: avoid overcounting bulk alloc in watermark check

shengminghu512 posted 1 patch 1 week, 2 days ago
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH linux-next] mm/page_alloc: avoid overcounting bulk alloc in watermark check
Posted by shengminghu512 1 week, 2 days ago
From: Shengming Hu <hu.shengming@zte.com.cn>

alloc_pages_bulk_noprof() only fills NULL slots and already tracks how many
entries are pre-populated via nr_populated.

The fast watermark check was adding nr_pages unconditionally, which can
overestimate the demand. Use (nr_pages - nr_populated) instead, as an 
upper bound on the remaining pages this call can still allocate without
scanning the whole array.

Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn>
---
 mm/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5fd9e4a03..90b978802 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5130,7 +5130,7 @@ unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid,
 
 		cond_accept_memory(zone, 0, alloc_flags);
 retry_this_zone:
-		mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK) + nr_pages;
+		mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK) + nr_pages - nr_populated;
 		if (zone_watermark_fast(zone, 0,  mark,
 				zonelist_zone_idx(ac.preferred_zoneref),
 				alloc_flags, gfp)) {
-- 
2.25.1
Re: [PATCH linux-next] mm/page_alloc: avoid overcounting bulk alloc in watermark check
Posted by Andrew Morton 1 week, 2 days ago
On Thu, 29 Jan 2026 22:38:14 +0800 "shengminghu512" <shengminghu512@qq.com> wrote:

> From: Shengming Hu <hu.shengming@zte.com.cn>
> 
> alloc_pages_bulk_noprof() only fills NULL slots and already tracks how many
> entries are pre-populated via nr_populated.
> 
> The fast watermark check was adding nr_pages unconditionally, which can
> overestimate the demand. Use (nr_pages - nr_populated) instead, as an 
> upper bound on the remaining pages this call can still allocate without
> scanning the whole array.

Thanks.

> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5130,7 +5130,7 @@ unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid,
>  
>  		cond_accept_memory(zone, 0, alloc_flags);
>  retry_this_zone:
> -		mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK) + nr_pages;
> +		mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK) + nr_pages - nr_populated;
>  		if (zone_watermark_fast(zone, 0,  mark,
>  				zonelist_zone_idx(ac.preferred_zoneref),
>  				alloc_flags, gfp)) {

So that little optimization hasn't been working for four years?
Re: [PATCH linux-next] mm/page_alloc: avoid overcounting bulk allocin watermark check
Posted by shengminghu512 1 week, 1 day ago
> On Thu, 29 Jan 2026 22:38:14 +0800 "shengminghu512" <shengminghu512@qq.com> wrote:
> 
> > From: Shengming Hu <hu.shengming@zte.com.cn>
> > 
> > alloc_pages_bulk_noprof() only fills NULL slots and already tracks how many
> > entries are pre-populated via nr_populated.
> > 
> > The fast watermark check was adding nr_pages unconditionally, which can
> > overestimate the demand. Use (nr_pages - nr_populated) instead, as an 
> > upper bound on the remaining pages this call can still allocate without
> > scanning the whole array.
> 
> Thanks.
> 
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -5130,7 +5130,7 @@ unsigned long alloc_pages_bulk_noprof(gfp_t gfp, int preferred_nid,
> >  
> >   cond_accept_memory(zone, 0, alloc_flags);
> >  retry_this_zone:
> > - mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK) + nr_pages;
> > + mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK) + nr_pages - nr_populated;
> >   if (zone_watermark_fast(zone, 0,  mark,
> >   zonelist_zone_idx(ac.preferred_zoneref),
> >   alloc_flags, gfp)) {
> 
> So that little optimization hasn't been working for four years?

Yeah, looks like it’s been conservative for a long time :)

It didn’t break correctness, but it likely made the fast watermark check
less effective by overestimating demand (counting already-populated entries
again), so we’d drop out of `zone_watermark_fast()` earlier and hit the
slow path more often.

--
With Best Regards,
Shengming