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 :) > > 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
