On 30 Mar 2026, at 7:17, Lorenzo Stoakes (Oracle) wrote: > On Sun, Mar 29, 2026 at 12:07:41PM +0800, WANG Rui wrote: >> Hi Zi, >> >>>> Now without READ_ONLY_THP_FOR_FS you're going to: >>>> >>>> | PF | MADV_COLLAPSE | khugepaged | >>>> |-----------|---------------|------------| >>>> large folio fs | ✓ | x | x | >>>> large folio + r/o | ✓ | ✓ | ✓ | >>>> >>>> And intentionally leaving behind the 'not large folio fs, r/o' case because >>>> those file systems need to implement large folio support. >>>> >>>> I guess we'll regress those users but we don't care? >>> >>> Yes. This also motivates FSes without large folio support to add large folio >>> support instead of relying on READ_ONLY_THP_FOR_FS hack. >> >> Interesting, thanks for making this feature unconditional. >> >> From my experiments, this is going to be a performance regression. >> >> Before this patch, even when the filesystem (e.g. btrfs without experimental) >> didn't support large folios, READ_ONLY_THP_FOR_FS still allowed read-only >> file-backed code segments to be collapsed into huge page mappings via >> khugepaged. >> >> After this patch, FilePmdMapped will always be 0 unless the filesystem >> supports >> large folios up to PMD order, and it doesn't look like that support will >> arrive >> anytime soon [1]. > > I think Matthew was being a little sarcastic there ;) but I suppose it's > hinting at the fact they need to get a move on. > >> >> Is there a reason we can't keep this hack while continuing to push >> filesystems >> toward proper large folio support? > > IMO - It's time for us to stop allowing filesystems to fail to implement what > mm requires of them, while still providing a hack to improve performance. > > Really this hack shouldn't have been there in the first place, but it was a > 'putting on notice' that filesystems need to support large folios, which > has been made amply clear to them for some time. > > So yes there will be regressions for filesystems which _still_ do not > implement this, I'd suggest you focus on trying to convince them to do so > (or send patches :) >
Thank Lorenzo for clarifying the intention of this patchset. Hi Rui, READ_ONLY_THP_FOR_FS is an experimental feature since 2019 and that means the feature can go away at any time. In addition, Matthew has made a heads-up on its removal [1] several months ago. We have not heard any objection since. It seems that you care about btrfs with large folio support. Have you talked to btrfs people on the timeline of moving the large folio support out of the experimental state? [1] https://lore.kernel.org/all/[email protected]/ >> >> I'm currently working on making the ELF loader more THP-friendly by adjusting >> the virtual address alignment of read-only code segments [2]. The data shows >> a >> noticeable drop in iTLB misses, especially for programs whose text size is >> just >> slightly larger than PMD_SIZE. That size profile is actually quite common for >> real-world binaries when using 2M huge pages. This optimization relies on >> READ_ONLY_THP_FOR_FS. If the availability of huge page mappings for code >> segments >> ends up depending on filesystem support, it will be much harder to take >> advantage >> of this in practice. [3] > > Yeah, again IMO - sorry, but tough. > > This is something filesystems need to implement, if they fail to do so, > that's on them. > >> >> [1] >> https://lore.kernel.org/linux-fsdevel/[email protected]/ >> [2] https://lore.kernel.org/linux-fsdevel/[email protected]/ >> [3] https://lore.kernel.org/linux-fsdevel/[email protected]/ >> >> Thanks, >> Rui > > Cheers, Lorenzo -- Best Regards, Yan, Zi
