Memory Folios Pull Request Pending For Linux 5.15

With the Linux 5.15 kernel merge window likely opening next week, Matthew Wilcox of Oracle has already sent in a prominent pull request to Linus Torvalds: the initial work around landing of the memory folios patches.

Memory folios is part of the effort for improving Linux memory management by introducing a new "folio" struct to help manage memory by allowing file-systems and the page cache to manage memory in chunks larger than the kernel page size.

Managing memory in 4KiB pages is a serious overhead. Many benchmarks benefit from a larger "page size". As an example, an earlier iteration of this idea which used compound pages (and wasn't particularly tuned) got a 7% performance boost when compiling the kernel.

Using compound pages or THPs exposes a weakness of our type system. Functions are often unprepared for compound pages to be passed to them, and may only act on PAGE_SIZE chunks. Even functions which are aware of compound pages may expect a head page, and do the wrong thing if passed a tail page.

We also waste a lot of instructions ensuring that we're not looking at a tail page. Almost every call to PageFoo() contains one or more hidden calls to compound_head(). This also happens for get_page(), put_page() and many more functions.

This patch series uses a new type, the struct folio, to manage memory. It converts enough of the page cache, iomap and XFS to use folios instead of pages, and then adds support for multi-page folios.

Wilcox sent in the code early ahead of the official merge window opening to provide Linus Torvalds with time to consider this low-level change.

For 5.15 the core memory management and page cache changes are in place. With the Linux 5.16 cycle is when XFS and other file-systems are expected to see adaptations for making use of memory folios and by the time of Linux 5.17 is likely when the multi-folios feature will be ready.

As to the current performance of the memory folios code, "The multi-page folios offer some improvement to some workloads. The 80% win is real, but appears to be an artificial benchmark (postgres startup, which isn't a serious workload). Real workloads (eg building the kernel, running postgres in a steady state, etc) seem to benefit between 0-10%. I haven't heard of any performance losses as a result of this series. Nobody has done any serious performance tuning; I imagine that tweaking the readahead algorithm could provide some more interesting wins. There are also other places where we could choose to create large folios and currently do not, such as writes that are larger than PAGE_SIZE."

More details via the pull request while waiting to see if Linus comments on the feature and/or decides to pull it come 5.15 merge window time.