Clarifying memory management with page folios

Have you looked at the patch series? I don't do everything in one go. Essentially I'm going one function at a time. It's pretty straightforward to convert between pages and folios. If you have a page and want the folio that contains it, that's spelled page_folio(page). If you have a folio and want the head page, that's &folio->page. If you have a folio and want the page that corresponds to a particular file index, that's folio_file_page(folio, index).

If you have a folio and want the n'th page, that's nth_page(&folio->page, n). Nobody's needed that one yet (and only people with really weird physical memory layouts need to do that ... alloc_folio() won't return a folio that you need to do that to. Others are working on maybe disallowing those from existing entirely, in which case (&folio->page + n) will do fine.

The performance improvements do not come from a small subset of the changes. You have to make the entire filesystem safe to handle memory in folios (no more references to, eg, PAGE_SIZE, unless you can prove they're safe, calls to kmap() have to be scrutinised. copy_(to|from)_iter() calls need care and attention, etc, etc). Once the filesystem declares itself safe by setting a bit in the fs_flags then the page cache can start handing it folios instead of pages.

I think what you're suggesting is essentially what I did here:
https://git.infradead.org/users/willy/pagecache.git/short...

I've given up on that approach because it's hard to find all the bugs. "Oh this interface takes a struct page. Does it take any struct page, or do I need to call it once for each tail page in the compound page?" I invite you to consider the various implementations of flush_dcache_page() ... and if you can figure out the answer, please let me know.