Memory Folios Merged For Linux 5.16
The proposed memory "folios" functionality for Linux 5.16 is happening! This low-level change to the Linux memory management code was merged today for this next kernel.
With memory folios not having landed for Linux 5.15 and lack of comment recently by Linus Torvalds on the matter, it wasn't clear if he was going to take in this latest folios pull request. But to some surprise, right away today he pulled in the initial folios code for Linux 5.16.
As explained in the PR:
The code is merged and ready to be built upon moving forward. It will be interesting to see the long-term (performance) impact of folios.
With memory folios not having landed for Linux 5.15 and lack of comment recently by Linus Torvalds on the matter, it wasn't clear if he was going to take in this latest folios pull request. But to some surprise, right away today he pulled in the initial folios code for Linux 5.16.
As explained in the PR:
The point of all this churn is to allow filesystems and the page cache to manage memory in larger chunks than PAGE_SIZE. The original plan was to use compound pages like THP does, but I ran into problems with some functions expecting only a head page while others expect the precise page containing a particular byte. The folio type allows a function to declare that it's expecting only a head page. Almost incidentally, this allows us to remove various calls to VM_BUG_ON(PageTail(page)) and compound_head().
This pull request converts just parts of the core MM and the page cache. For 5.17, we intend to convert various filesystems (XFS and AFS are ready; other filesystems may make it) and also convert more of the MM and page cache to folios. For 5.18, multi-page folios should be ready.
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.
The code is merged and ready to be built upon moving forward. It will be interesting to see the long-term (performance) impact of folios.
Add A Comment