THP support for btrfs

THP support for btrfs

[Matthew Wilcox]

I was pointed at the patches posted this week for sub-page support in
btrfs, and I thought it might be a good idea to mention that THP support
is going to hit many of the same issues as sub-PAGE_SIZE blocks, so if
you're thinking about sub-page block sizes, it might be a good idea to
add THP support at the same time, or at least be aware of it when you're
working on those patches to make THP work in the future.

While the patches have not entirely landed yet, complete (in that it
passes xfstests on my laptop) support is available here:
http://git.infradead.org/users/willy/pagecache.git

About 40 of the 100 patches are in Andrew Morton's tree or the iomap
tree waiting for the next merge window, and I'd like to get the rest
upstream in the merge window after that.  About 20-25 of the patches are
to iomap/xfs and the rest are generic MM/FS support.

The first difference you'll see after setting the flag indicating
that your filesystem supports THPs is transparent huge pages being
passed to ->readahead().  You should submit I/Os to read every byte
in those pages, not just the first PAGE_SIZE bytes ;-)  Likewise, when
writepages/writepage is called, you'll want to write back every dirty
byte in that page, not just the first PAGE_SIZE bytes.

If there's a page error (I strongly recommend error injection), you'll
also see these pages being passed to ->readpage and ->write_begin
without being PageUptodate, and again, you'll have to handle reads
for the parts of the page which are not Uptodate.

You'll have to handle invalidatepage being called from the truncate /
page split path.

page_mkwrite can be called with a tail page.  You should be sure to mark
the entire page as dirty (we only track dirty state on a per-THP basis,
not per-subpage basis).

---

I see btrfs is switching to iomap for the directIO path.  Has any
consideration been given to switching to iomap for the buffered I/O path?
Or is that just too much work?

Re: THP support for btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 2603 bytes --]



On 2020/9/17 上午11:30, Matthew Wilcox wrote:
> I was pointed at the patches posted this week for sub-page support in
> btrfs, and I thought it might be a good idea to mention that THP support
> is going to hit many of the same issues as sub-PAGE_SIZE blocks, so if
> you're thinking about sub-page block sizes, it might be a good idea to
> add THP support at the same time, or at least be aware of it when you're
> working on those patches to make THP work in the future.

That looks pretty interesting,

> 
> While the patches have not entirely landed yet, complete (in that it
> passes xfstests on my laptop) support is available here:
> http://git.infradead.org/users/willy/pagecache.git
> 
> About 40 of the 100 patches are in Andrew Morton's tree or the iomap
> tree waiting for the next merge window, and I'd like to get the rest
> upstream in the merge window after that.  About 20-25 of the patches are
> to iomap/xfs and the rest are generic MM/FS support.
> 
> The first difference you'll see after setting the flag indicating
> that your filesystem supports THPs is transparent huge pages being
> passed to ->readahead().  You should submit I/Os to read every byte
> in those pages, not just the first PAGE_SIZE bytes ;-)  Likewise, when
> writepages/writepage is called, you'll want to write back every dirty
> byte in that page, not just the first PAGE_SIZE bytes.
> 
> If there's a page error (I strongly recommend error injection), you'll
> also see these pages being passed to ->readpage and ->write_begin
> without being PageUptodate, and again, you'll have to handle reads
> for the parts of the page which are not Uptodate.
> 
> You'll have to handle invalidatepage being called from the truncate /
> page split path.
> 
> page_mkwrite can be called with a tail page.  You should be sure to mark
> the entire page as dirty (we only track dirty state on a per-THP basis,
> not per-subpage basis).
> 
> ---
> 
> I see btrfs is switching to iomap for the directIO path.  Has any
> consideration been given to switching to iomap for the buffered I/O path?

Yep, IIRC Goldwyn is already working on that.

Furthermore, we're even considering to utilize iomap for subpage
metadata support (currently we set metadata Private for metadata, and
for subpage, we don't utilize page::private at all)

But that would happen in the future, at least after RW subpage support.

And I'm definitely going to add that support in the future, and
hopefully with much smaller code change.

Thanks,
Qu

> Or is that just too much work?
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: THP support for btrfs

[Christoph Hellwig]

On Thu, Sep 17, 2020 at 04:30:21AM +0100, Matthew Wilcox wrote:
> I was pointed at the patches posted this week for sub-page support in
> btrfs, and I thought it might be a good idea to mention that THP support
> is going to hit many of the same issues as sub-PAGE_SIZE blocks, so if
> you're thinking about sub-page block sizes, it might be a good idea to
> add THP support at the same time, or at least be aware of it when you're
> working on those patches to make THP work in the future.

I think the right path is to switch btrfs to use iomap for buffered I/O
as well and piggy back on all the work you've done..