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]. Is there a reason we can't keep this hack while continuing to push filesystems toward proper large folio support? 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] [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
