All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: libaokun@huaweicloud.com
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz,
	surenb@google.com, jackmanb@google.com, hannes@cmpxchg.org,
	ziy@nvidia.com, willy@infradead.org, shakeel.butt@linux.dev,
	jack@suse.cz, yi.zhang@huawei.com, yangerkun@huawei.com,
	libaokun1@huawei.com
Subject: Re: [PATCH] mm/page_alloc: don't warn about large allocations with __GFP_NOFAIL
Date: Wed, 5 Nov 2025 09:05:02 +0100	[thread overview]
Message-ID: <aQsFLn6VDFOXuvxv@tiehlicka> (raw)
In-Reply-To: <20251105074106.3508870-1-libaokun@huaweicloud.com>

On Wed 05-11-25 15:41:06, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
> 
> Filesystems use __GFP_NOFAIL to allocate block-sized folios for metadata
> reads at critical points, since they cannot afford to go read-only,
> shut down, or enter an inconsistent state due to memory pressure.
> 
> Currently, attempting to allocate page units greater than order-1 with
> the __GFP_NOFAIL flag triggers a WARN_ON() in __alloc_pages_slowpath().
> However, filesystems supporting large block sizes (blocksize > PAGE_SIZE)
> can easily require allocations larger than order-1.
> 
> As Matthew Wilcox noted, if we have a filesystem with 64KiB sectors, there
> will be many clean folios in the page cache that are 64KiB or larger.
> 
> With gfp flags and order already included in the OOM report, both
> Vlastimil Babka and Michal Hocko suggested that we can take the risk of
> removing this warning first and then observe whether a large number of
> related OOM reports appear.
> 
> If that happens, we can consider adding special handling in other places.
> 
> Suggested-by: Matthew Wilcox <willy@infradead.org>
> Link: https://lore.kernel.org/all/aQPX1-XWQjKaMTZB@casper.infradead.org
> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> Link: https://lore.kernel.org/all/188a95ba-6384-4319-bb74-c0d9ec6c4079@suse.cz
> Suggested-by: Michal Hocko <mhocko@suse.com>
> Link: https://lore.kernel.org/all/aQotQBjnDDeL_wHx@tiehlicka
> Signed-off-by: Baokun Li <libaokun1@huawei.com>

Thanks for referencing above links which are providing a useful insight
for future reference. I would just add a link to Matthew explanation why
kvmalloc is not an option
Link: https://lore.kernel.org/all/aQTHMI3t5mNXp0M1@casper.infradead.org/T/#u
Acked-by: Michal Hocko <mhocko@suse.com>

> ---
> 
> RFC: https://lore.kernel.org/all/20251031061350.2052509-1-libaokun@huaweicloud.com
> 
>  mm/page_alloc.c | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fb91c566327c..e4efda1158b2 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4683,11 +4683,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>  	int reserve_flags;
>  
>  	if (unlikely(nofail)) {
> -		/*
> -		 * We most definitely don't want callers attempting to
> -		 * allocate greater than order-1 page units with __GFP_NOFAIL.
> -		 */
> -		WARN_ON_ONCE(order > 1);
>  		/*
>  		 * Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM,
>  		 * otherwise, we may result in lockup.
> -- 
> 2.46.1

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2025-11-05  8:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-05  7:41 [PATCH] mm/page_alloc: don't warn about large allocations with __GFP_NOFAIL libaokun
2025-11-05  8:05 ` Michal Hocko [this message]
2025-11-05  8:11   ` Baokun Li
2025-11-05  8:09 ` Vlastimil Babka

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=aQsFLn6VDFOXuvxv@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=jackmanb@google.com \
    --cc=libaokun1@huawei.com \
    --cc=libaokun@huaweicloud.com \
    --cc=linux-mm@kvack.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --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.