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

[Matthew Wilcox <willy@infradead.org>]

On Sun, Dec 03, 2023 at 11:11:14PM +0300, Viacheslav Dubeyko wrote:
> 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?

The problem I'm trying to avoid is that when we allocate an order-1
folio, we only have two struct pages for the folio.  At the moment, we
have the deferred_list stored in the third struct page of the folio.
There isn't quite space to squeeze it into the second struct page on
32-bit systems -- we have

_flags_1		flags
_head_1			lru.head
_folio_avail		lru.tail
_entire_mapcount	mapping
_nr_pages_mapped	index
_pincount		private

after that we'd start to collide with _mapcount (which is still used
per-page) and _refcount (which must be 0 on tail pages).  We have one
word available (_folio_avail), but we'd need two to fit in a list_head.

We might be able to reengineer things so that we don't need a list_head
for deferred_list.  eg we could store deferred-split folios in an
xarray and only store the index in the folio.  Or we could decline to
deferred-split folios that are order-1.  I haven't looked into it in
detail, but I feel like this might be an acceptable approach.

I was talking with Darrick on Friday and he convinced me that this is
something we're going to need to fix sooner rather than later for the
benefit of devices with block size 8kB.  So it's definitely on my todo
list, but I haven't investigated in any detail yet.

Thanks for raising the issue; it gave me a good opportunity to explain
my current thinking on the problem.  Adding linux-mm for insights from
the MM audience.