mbox series

[00/15] ubifs folio conversion

Message ID 20240120230824.2619716-1-willy@infradead.org
Headers show
Series ubifs folio conversion | expand

Message

Matthew Wilcox Jan. 20, 2024, 11:08 p.m. UTC 
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 ;-)

The first patch fixes a misplaced call to SetPageUptodate which has been
with us since the initial merge of ubifs.  It looks to be a pretty hard
race to hit, which is why it probably hasn't affected anyone.

With my usual test config, this saves about 2kB of kernel text (almost
1%).  Some functions shrink more than others, eg ubifs_write_begin
reduces by almost a third.  YMMV with different configs.

I've done a few other updates while I'm in here; eg setting/clearing
PageError is pointless because the VFS doesn't use it and ubifs doesn't
test it.  And we're phasing out use of PagePrivate / folio_test_private()
in favour of just testing whether folio->private is set.

I ran this through xfstests and it didn't seem any worse.

Matthew Wilcox (Oracle) (15):
  ubifs: Set page uptodate in the correct place
  ubifs: Convert from writepage to writepages
  ubifs: Convert ubifs_writepage to use a folio
  ubifs: Use a folio in do_truncation()
  ubifs: Convert do_writepage() to take a folio
  ubifs: Convert ubifs_vm_page_mkwrite() to use a folio
  ubifs: Convert write_begin_slow() to use a folio
  ubifs: Convert ubifs_write_begin() to use a folio
  ubifs: Convert ubifs_write_end() to use a folio
  ubifs: Convert do_readpage() to take a folio
  ubifs: Convert allocate_budget() to work on a folio
  ubifs: Convert cancel_budget() to take a folio
  ubifs: Pass a folio into ubifs_bulk_read() and ubifs_do_bulk_read()
  ubifs: Use a folio in ubifs_do_bulk_read()
  ubifs: Convert populate_page() to take a folio

 Documentation/mm/page_cache.rst |  10 +
 fs/ubifs/file.c                 | 443 ++++++++++++++++----------------
 2 files changed, 232 insertions(+), 221 deletions(-)

Comments

Richard Weinberger Jan. 23, 2024, 7:33 a.m. UTC | #1 
Matthew,

----- Ursprüngliche Mail -----
> Von: "Matthew Wilcox" <willy@infradead.org>
> An: "richard" <richard@nod.at>
> CC: "Matthew Wilcox" <willy@infradead.org>, "linux-mtd" <linux-mtd@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?

> The first patch fixes a misplaced call to SetPageUptodate which has been
> with us since the initial merge of ubifs.  It looks to be a pretty hard
> race to hit, which is why it probably hasn't affected anyone.

Thanks a lot for identifying and fixing this one!

> With my usual test config, this saves about 2kB of kernel text (almost
> 1%).  Some functions shrink more than others, eg ubifs_write_begin
> reduces by almost a third.  YMMV with different configs.
> 
> I've done a few other updates while I'm in here; eg setting/clearing
> PageError is pointless because the VFS doesn't use it and ubifs doesn't
> test it.  And we're phasing out use of PagePrivate / folio_test_private()
> in favour of just testing whether folio->private is set.
> 
> 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?

Thanks,
//richard
Matthew Wilcox Jan. 24, 2024, 5:01 a.m. UTC | #2 
On Tue, Jan 23, 2024 at 08:33:49AM +0100, Richard Weinberger wrote:
> Matthew,
> 
> ----- Ursprüngliche Mail -----
> > Von: "Matthew Wilcox" <willy@infradead.org>
> > An: "richard" <richard@nod.at>
> > CC: "Matthew Wilcox" <willy@infradead.org>, "linux-mtd" <linux-mtd@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.
Zhihao Cheng Jan. 25, 2024, 2:05 a.m. UTC | #3 
在 2024/1/24 13:01, Matthew Wilcox 写道:
> On Tue, Jan 23, 2024 at 08:33:49AM +0100, Richard Weinberger wrote:
>> Matthew,
>>
>> ----- Ursprüngliche Mail -----
>>> Von: "Matthew Wilcox" <willy@infradead.org>
>>> An: "richard" <richard@nod.at>
>>> CC: "Matthew Wilcox" <willy@infradead.org>, "linux-mtd" <linux-mtd@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.

Ext4 could gain a good performance based on large folio[1], one 
important reason is that blocks allocation method is changed as batch 
allocation from one by one. There is a difference between UBIFS and ext4 
on IO logic, so I'm not sure how much performance the large folio will 
bring to UBIFS. I think page will be replaced by folio some day, so 
these patches can be a folio switching and a preparation for large folio 
support on UBIFS, personally I think.

[1] https://lwn.net/Articles/956575/
Matthew Wilcox Feb. 15, 2024, 8:46 p.m. UTC | #4 
On Sat, Jan 20, 2024 at 11:08:08PM +0000, Matthew Wilcox (Oracle) wrote:
> 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 ;-)

It's been four weeks ... do I need to do anything to make sure this hits
the next merge window?
Richard Weinberger Feb. 15, 2024, 8:54 p.m. UTC | #5 
----- Ursprüngliche Mail -----
> Von: "Matthew Wilcox" <willy@infradead.org>
> On Sat, Jan 20, 2024 at 11:08:08PM +0000, Matthew Wilcox (Oracle) wrote:
>> 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 ;-)
> 
> It's been four weeks ... do I need to do anything to make sure this hits
> the next merge window?

Nope, I'll add it to ubifs/next soon. :-)

Thanks,
//richard
Richard Weinberger Feb. 25, 2024, 10:13 p.m. UTC | #6 
----- Ursprüngliche Mail -----
> ----- Ursprüngliche Mail -----
>> Von: "Matthew Wilcox" <willy@infradead.org>
>> On Sat, Jan 20, 2024 at 11:08:08PM +0000, Matthew Wilcox (Oracle) wrote:
>>> 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 ;-)
>> 
>> It's been four weeks ... do I need to do anything to make sure this hits
>> the next merge window?
> 
> Nope, I'll add it to ubifs/next soon. :-)

I'm not sure whether you're checking the MTD patchwork status.
So, patches applied. :)

Thanks,
//richard