Re: [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Josef Bacik <josef@toxicpanda.com>]

On Thu, Aug 22, 2024 at 01:07:52PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> > 在 2024/8/22 12:35, Matthew Wilcox 写道:
> > > > -	while (cur < page_start + PAGE_SIZE) {
> > > > +	while (cur < folio_start + PAGE_SIZE) {
> > > 
> > > Presumably we want to support large folios in btrfs at some point?
> > 
> > Yes, and we're already working towards that direction.
> > 
> > > I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
> > > be a bit of a regression for btrfs if it doesn't have large folio
> > > support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?
> > 
> > AFAIK we're only going to support larger folios to support larger than
> > PAGE_SIZE sector size so far.
> 
> Why do you not want the performance gains from using larger folios?
> 
> > So every folio is still in a fixed size (sector size, >= PAGE_SIZE).
> > 
> > Not familiar with transparent huge page, I thought transparent huge page
> > is transparent to fs.
> > 
> > Or do we need some special handling?
> > My uneducated guess is, we will get a larger folio passed to readpage
> > call back directly?
> 
> Why do you choose to remain uneducated?  It's not like I've been keeping
> all of this to myself for the past five years.  I've given dozens of
> presentations on it, including plenary sessions at LSFMM.  As a filesystem
> developer, you must want to not know about it at this point.
> 

Or, a more charitable read, is that this particular developer has never been to
LSFMMBPF/Plumbers/anywhere you've given a talk.

This stuff is complicated, I don't even know what's going on half the time, much
less a developer who exclusively works on btrfs internals.

There's a lot of things to know in this space, we can't all know what's going on
in every corner.

As for the topic at hand, I'm moving us in the direction of an iomap conversion
so we can have the large folio support, regardless of the underlying
sectorsize/metadata block size.  Unfortunately there's a lot of fundamental
changes that need to be made to facilitate that, and those are going to take
some time to test and validate to make sure we didn't break anything.  In the
meantime we're going to be in this weird limbo states while I tackle the
individual problem areas.

My priorities are split between getting this to work and fuse improvements to
eventually no longer need to have file systems in the kernel to avoid all this
in general, so it's going to be spurty, but I hope to have this work done by the
next LSFMMBPF.  Thanks,

Josef