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@xxxxxxxxxxxxx
