[PATCH 00/15] ubifs folio conversion

[Matthew Wilcox]

On Tue, Jan 23, 2024 at 08:33:49AM +0100, Richard Weinberger wrote:
> Matthew,
> 
> ----- Ursprüngliche Mail -----
> > Von: "Matthew Wilcox" <willy at infradead.org>
> > An: "richard" <richard at nod.at>
> > CC: "Matthew Wilcox" <willy at infradead.org>, "linux-mtd" <linux-mtd at lists.infradead.org>
> > Gesendet: Sonntag, 21. Januar 2024 00:08:08
> > Betreff: [PATCH 00/15] ubifs folio conversion
> 
> > This patchset converts ubifs to use folios throughout.  I made some
> > attempt to support large folios, but more work definitely needs to be
> > done before it can be enabled.  It's not clear to me whether it's worth
> > doing, so I've left that for you ;-)
> 
> what is the benefit of large folios?

For another purpose, I just wrote this up.  Possibly there are more
benefits, but these are the ones I remembered just now:

But why should a filesystem put in the effort to support large folios
(aka multi-page folios)?

    Lower overheads
        Fewer calls to the page allocator
        Shorter LRU list helps vmscan age memory
        Fewer calls to the page cache for large read()/write()
        Fewer calls to the architecture code for handling faults in mmaped files
        Potential use of larger TLB entries (eg contPTE / NAPOT)
    Being a better kernel citizen
        The more code using large folios, the easier it is to allocate large folios

The costs may outweigh the benefits. I would not invest time in making
iso9660, adfs or efs support large folios. But for filesystems which
are used every day (XFS, NFS, ext4, btrfs, ...) the benefit is very much
worth the cost.

> > I ran this through xfstests and it didn't seem any worse.
> 
> Can you recommend a specific real load workload to stress test your changes?

Not really.  Everything should work just as it did before.  I doubt
you'd be able to see any performance differences with, eg, a kernel
compile.  There's usually a few % gain when enabling large folios.