Re: THP support for btrfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux