Memory folios and Btrfs

Memory folios and Btrfs

[Neal Gompa]

Hey all,

I've been peripherally following the work on memory folios that
Matthew Wilcox has been doing[1], and I started wondering if Btrfs
would benefit from it after the subpage stuff is done? It seems like
adopting this would be an opportunity to decouple Btrfs from mm page
size entirely, while allowing us to pick more optimal settings for
Btrfs regardless of architecture.

Am I on the right track or completely off-base?

Thanks in advance and best regards!

[1]: https://lore.kernel.org/lkml/20210715033704.692967-1-willy@infradead.org/

-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: Memory folios and Btrfs

[Nikolay Borisov]

On 15.07.21 г. 13:26, Neal Gompa wrote:
> I've been peripherally following the work on memory folios that
> Matthew Wilcox has been doing[1], and I started wondering if Btrfs
> would benefit from it after the subpage stuff is done? It seems like
> adopting this would be an opportunity to decouple Btrfs from mm page
> size entirely, while allowing us to pick more optimal settings for
> Btrfs regardless of architecture.
The reason btrfs is coupled with the page size is not due to memory
folios but due to having the btree inode. So converting to memory folios
won't help on that front.

Re: Memory folios and Btrfs

[Matthew Wilcox]

On Thu, Jul 15, 2021 at 06:26:42AM -0400, Neal Gompa wrote:
> I've been peripherally following the work on memory folios that
> Matthew Wilcox has been doing[1], and I started wondering if Btrfs
> would benefit from it after the subpage stuff is done? It seems like
> adopting this would be an opportunity to decouple Btrfs from mm page
> size entirely, while allowing us to pick more optimal settings for
> Btrfs regardless of architecture.

All filesystems will benefit from using folios.  Once the initial
~92 patches have landed, using folios throughout means fewer calls
to compound_head() and so smaller code size and presumably slightly
faster code.  All filesystems should be converted to use folios rather
than pages.

Supporting multi-page folios should also benefit every filesystem.  The VM
gets to manage file-backed memory in larger units, so filesystems will
have less work to do (eg readahead will bring in fewer, larger folios,
writeback will also write out fewer, larger folios).

I look forward to working with btrfs people to figure out how to track
the per-block state without using buffer_heads.  I have that working for
XFS with iomap, but XFS tracks much less state (just uptodate, which is
presumed to all be dirty if any of it is dirty).  Looking at the btrfs
subpage state (in Linus' current tree), it tracks 4 bits of information
per block; uptodate, error, dirty and writeback.

As far asa supporting block sizes > PAGE_SIZE, this is something I've
had in mind for a long time.  My current thinking is that we can take a
few bits in mapping->flags to set the minimum folio order to allocate.
There will be a few places to change, but it should be doable.  Some are
concerned that we won't be able to allocate high-order folios, but my
thinking is that if the page cache is using high-order folios, then
we'll be able to reclaim high-order folios from the page cache.
There's only one way to know what will happen.