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

[Matthew Wilcox <willy@infradead.org>]

On Fri, Oct 31, 2025 at 11:12:16AM +0100, Vlastimil Babka wrote:
> On 10/31/25 08:25, Michal Hocko wrote:
> > 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?
> 
> The thread under Link: suggests xfs has its own vmalloc callback. But it's
> not one of the 5 options listed, so it's good question how difficult would
> be to implement that for ext4 or in general.

It's implicit in options 1-4.  Today, the buffer cache is an alias into
the page cache.  The page cache can only store folios.  So to use
vmalloc, we either have to make folios discontiguous, stop the buffer
cache being an alias into the page cache, or stop ext4 from using the
buffer cache.

> > 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.

Maybe Baokun's explanation for why this is unlikel to be a problem in
practice didn't make sense to you.  Let me try again, perhaps being more
explicit about things which an fs developer would know but an MM person
might not realise.

Hard drive manufacturers are absolutely gagging to ship drives with a
64KiB sector size.  Once they do, the minimum transfer size to/from a
device becomes 64KiB.  That means the page cache will cache all files
(and fs metadata) from that drive in contiguous 64KiB chunks.  That means
that when reclaim shakes the page cache, it's going to find a lot of
order-4 folios to free ... which means that the occasional GFP_NOFAIL
order-4 allocation is going to have no trouble finding order-4 pages to
satisfy the allocation.

Now, the problem is the non-filesystems which may now take advantage of
this to write lazy code.  It'd be nice if we had some token that said
"hey, I'm the page cache, I know what I'm doing, trust me if I'm doing a
NOFAIL high-order allocation, you can reclaim one I've already allocated
and everything will be fine".  But I can't see a way to put that kind
of token into our interfaces.

> >> +/*
> >> + * 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
> 
> This is a bit confusing to me since we are talking about block size. Are
> filesystems with these large block sizes only possible to mount with a
> kernel with THPs?

For the moment, yes.  It's an artefact of how large folio support was
originally developed.  It's one of those things that's only a problem for
weirdoes who compile their own kernels because all distros have turned
it on since basically forever.  Also some minority architectures don't
support it yet.  Anyway, fixing this is on the todo list, but it's not
a high priority.