Re: Issue with 8K folio size in __filemap_get_folio()

[Dave Chinner <david@fromorbit.com>]

On Sun, Dec 03, 2023 at 11:11:14PM +0300, Viacheslav Dubeyko wrote:
> Hi Matthew,
> 
> I believe we have issue in __filemap_get_folio() logic for the case of 8K folio size (order is equal to 1).
> 
> Let’s imagine we have such code and folio is not created yet for index == 0:
> 
> fgf_t fgp_flags = FGP_WRITEBEGIN;
> 
> mapping_set_large_folios(mapping);
> fgp_flags |= fgf_set_order(8192);
> 
> folio = __filemap_get_folio(mapping, 0, fgf_flags, mapping_gfp_mask(mapping));
> 
> As a result, we received folio with size 4K but not 8K as it was expected:

Getting a 4kB folio back in this case is expected behaviour.

> So, why do we correct the order to zero always if order is equal to one?
> It sounds for me like incorrect logic. Even if we consider the troubles
> with memory allocation, then we will try allocate, for example, 16K, exclude 8K,
> and, finally, will try to allocate 4K. This logic puzzles me anyway.
> Do I miss something here?

That a high-order folio requires 3 struct page headers to hold all
the internal state, and there are only two struct page headers
available for an 8kB folio.

Hence order-1 folios don't exist...

-Dave.
-- 
Dave Chinner
david@fromorbit.com