Re: [PATCH RFC] mm: allow __GFP_NOFAIL allocation up to BLK_MAX_BLOCK_SIZE to support LBS

[Michal Hocko <mhocko@suse.com>]

On Fri 31-10-25 14:13:50, 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 noted, if we have a filesystem with 64KiB sectors, there will
> be many clean folios in the page cache that are 64KiB or larger.
> 
> Therefore, to avoid the warning when LBS is enabled, we relax this
> restriction to allow allocations up to BLK_MAX_BLOCK_SIZE. The current
> maximum supported logical block size is 64KiB, meaning the maximum order
> handled here is 4.

Would be using kvmalloc an option instead of this?

This change doesn't really make much sense to me TBH. While the order=1
is rather arbitrary it is an internal allocator constrain - i.e. order which
the allocator can sustain for NOFAIL requests is directly related to
memory reclaim and internal allocator operation rather than something as
external as block size. If the allocator needs to support 64kB NOFAIL
requests because there is a strong demand for that then fine and we can
see whether this is feasible.

Please keep in mind that 64kb > PAGE_ALLOC_COSTLY_ORDER and that is
where page allocator behavior changes considerably (e.g. oom killer is
not invoked so the allocation could stall for ever). So it is not as
simple as say this just going to work fine.

> Suggested-by: Matthew Wilcox <willy@infradead.org>
> Link: https://lore.kernel.org/all/aQPX1-XWQjKaMTZB@casper.infradead.org
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> ---
>  mm/page_alloc.c | 25 ++++++++++++++++++++-----
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index fb91c566327c..913b9baa24b4 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4663,6 +4663,25 @@ check_retry_cpuset(int cpuset_mems_cookie, struct alloc_context *ac)
>  	return false;
>  }
>  
> +/*
> + * We most definitely don't want callers attempting to
> + * allocate greater than order-1 page units with __GFP_NOFAIL.
> + *
> + * However, folio allocations up to BLK_MAX_BLOCK_SIZE with
> + * __GFP_NOFAIL should always be supported.
> + */
> +static inline void check_nofail_max_order(unsigned int order)
> +{
> +	unsigned int max_order = 1;
> +
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +	if (PAGE_SIZE << 1 < SZ_64K)
> +		max_order = get_order(SZ_64K);
> +#endif
> +
> +	WARN_ON_ONCE(order > max_order);
> +}
> +
>  static inline struct page *
>  __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>  						struct alloc_context *ac)
> @@ -4683,11 +4702,7 @@ __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);
> +		check_nofail_max_order(order);
>  		/*
>  		 * Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM,
>  		 * otherwise, we may result in lockup.
> -- 
> 2.46.1

-- 
Michal Hocko
SUSE Labs