From: Balbir Singh <balbirs@nvidia.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Salvatore Dipietro <dipiets@amazon.it>,
Christoph Hellwig <hch@lst.de>, Dave Chinner <dgc@kernel.org>,
Matt Fleming <matt@readmodwrite.com>,
Mel Gorman <mgorman@techsingularity.net>,
Michal Hocko <mhocko@suse.com>,
Suren Baghdasaryan <surenb@google.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Zi Yan <ziy@nvidia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES
Date: Thu, 29 Oct 2026 18:04:19 +1100 [thread overview]
Message-ID: <auLv88bDy-oZKIC4@parvat> (raw)
In-Reply-To: <20261028171719.2043421-3-hannes@cmpxchg.org>
On Wed, Oct 28, 2026 at 01:15:54PM -0400, Johannes Weiner wrote:
> 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH
> non-blocking allocations accesses reserves") stopped handing out
> reserve access for ALLOC_NON_BLOCK on its own: the extra 25% below the
> min watermark is now only granted on top of ALLOC_MIN_RESERVE. But the
> flag was left in ALLOC_RESERVES, which produces something odd:
>
> With the ALLOC_RESERVES match, __zone_watermark_unusable_free() doesn't
> subtract the free highatomic pages for them. So in the slowpath, they
> get to consume regular blocks below the min watermark by the number of
> free highatomic pages. The highatomic reserve is capped at 1% of the
> zone, which on any decently sized machine is a multiple of the min
> watermark: GFP_NOWAIT can drain regular memory to zero.
>
> The user-visible result is brutal hiccups during bursts of GFP_NOWAIT
> allocations under memory pressure. This was found in review and
> reproduced with a synthetic burst, not observed in production, but the
> sequence of events is a realistic one: On a 32G box with an anonymous
> working set, swap, and a filled 290M highatomic reserve, a GFP_NOWAIT
> burst drove regular free memory in the 28G Normal zone (min=60M) to
> 28M, 0.8M and 0.6M in three runs. Swapout failed to allocate its swap
> table, reclaim scanned 13M pages to reclaim 200k, page faults stalled
> for tens to hundreds of milliseconds. The machine survives it, but not
> by design: direct reclaimers eventually fail and start unreserving
> highatomic blocks, until the allocation succeeds or the reserve is
> gone and the OOM killer runs. That reserve exists for high-order
> atomic allocations; here it is destroyed to bail out a GFP_NOWAIT
> consumer that was never entitled to the memory.
>
> Remove ALLOC_NON_BLOCK from ALLOC_RESERVES. With that, the GFP_NOWAIT
> burst is stopped short at the min watermark. No direct reclaim, no
> stalls, no failed allocations, and the highatomic reserve stays intact
> for the requests it exists for.
>
> __zone_watermark_ok() is unaffected, since everything it keys on
> ALLOC_NON_BLOCK is already nested under ALLOC_MIN_RESERVE. Update the
> flag comments accordingly: ALLOC_NON_BLOCK just means the caller can't
> block; the reserve math belongs with ALLOC_MIN_RESERVE.
>
> GFP_ATOMIC order-0 requests have a milder version of the same problem.
> Through ALLOC_MIN_RESERVE they also count the free highatomic pages in
> their watermark check, but rmqueue_buddy() serves them regular pages
> first and only falls back to the reserve once those are gone. They can
> still push regular free memory to 37.5% of min minus the free
> highatomic pages before the reserve is touched. Unlike GFP_NOWAIT they
> are entitled to the reserve, so this needs the watermark check and the
> freelist order reworked together, and is left to a separate patch.
>
> Fixes: 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations accesses reserves")
> Cc: stable@vger.kernel.org
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> ---
> mm/page_alloc.h | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/mm/page_alloc.h b/mm/page_alloc.h
> index 9c3c2830acb0..7097ea1805f6 100644
> --- a/mm/page_alloc.h
> +++ b/mm/page_alloc.h
> @@ -32,12 +32,11 @@
> #define ALLOC_OOM ALLOC_NO_WATERMARKS
> #endif
>
> -#define ALLOC_NON_BLOCK 0x10 /* Caller cannot block. Allow access
> - * to 25% of the min watermark or
> - * 62.5% if __GFP_HIGH is set.
> - */
> +#define ALLOC_NON_BLOCK 0x10 /* Caller cannot block. */
> #define ALLOC_MIN_RESERVE 0x20 /* __GFP_HIGH set. Allow access to 50%
> - * of the min watermark.
> + * of the min watermark, or 62.5% if
> + * the caller cannot block either
> + * (ALLOC_NON_BLOCK).
> */
> #define ALLOC_CPUSET 0x40 /* check for correct cpuset */
> #define ALLOC_CMA 0x80 /* allow allocations from CMA areas */
> @@ -58,7 +57,7 @@
> #define ALLOC_NO_CODETAG 0x1000
>
> /* Flags that allow allocations below the min watermark. */
> -#define ALLOC_RESERVES (ALLOC_NON_BLOCK|ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM)
> +#define ALLOC_RESERVES (ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM)
>
> /* Flags that mean GFP_ATOMIC */
> #define ALLOC_MASK_ATOMIC (ALLOC_NON_BLOCK|ALLOC_MIN_RESERVE)
>
Acked-by: Balbir Singh <balbirs@nvidia.com>
next prev parent reply other threads:[~2026-10-29 7:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 17:15 [PATCH v2 0/2] mm: page_alloc: fix reserve access for non-blocking requests Johannes Weiner
2026-10-28 17:15 ` [PATCH 1/2] mm: page_alloc: do not give all non-blocking requests reserve access Johannes Weiner
2026-10-29 6:59 ` Balbir Singh
2026-10-29 9:49 ` Vlastimil Babka (SUSE)
2026-10-28 17:15 ` [PATCH 2/2] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES Johannes Weiner
2026-10-29 7:04 ` Balbir Singh [this message]
2026-10-29 9:51 ` Vlastimil Babka (SUSE)
-- strict thread matches above, loose matches on Subject: below --
2026-09-06 0:42 [PATCH v4] mm/page_alloc: avoid direct compaction for costly __GFP_NORETRY allocations Andrew Morton
2026-09-10 11:46 ` Salvatore Dipietro
2026-09-11 15:59 ` Johannes Weiner
2026-09-16 11:24 ` Vlastimil Babka (SUSE)
2026-09-16 15:58 ` Johannes Weiner
2026-09-18 7:05 ` Vlastimil Babka (SUSE)
2026-09-21 14:37 ` Johannes Weiner
2026-09-21 14:39 ` [PATCH 2/2] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES Johannes Weiner
2026-09-22 12:06 ` Vlastimil Babka (SUSE)
2026-09-22 14:00 ` Johannes Weiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=auLv88bDy-oZKIC4@parvat \
--to=balbirs@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=brendan.jackman@linux.dev \
--cc=dgc@kernel.org \
--cc=dipiets@amazon.it \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matt@readmodwrite.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.