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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel