On 13 Apr 2026, at 16:33, Matthew Wilcox wrote: > On Mon, Apr 13, 2026 at 03:20:23PM -0400, Zi Yan wrote: >> After READ_ONLY_THP_FOR_FS Kconfig is removed, this check becomes dead >> code. >> >> This changes hugepage_pmd_enabled() semantics. Previously, with >> READ_ONLY_THP_FOR_FS enabled, hugepage_pmd_enabled() returned true whenever >> /sys/kernel/mm/transparent_hugepage/enabled was set to "always" or >> "madvise". >> >> After this change, hugepage_pmd_enabled() is governed only by the anon and >> shmem PMD THP controls. As a result, khugepaged collapse for file-backed >> folios no longer runs unconditionally under the top-level THP setting, and >> now depends on the anon/shmem PMD configuration. > > This seems like it'll turn off khugepaged too easily. I would have > thought we'd want: > > - if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && > - hugepage_global_enabled()) > + if (hugepage_global_enabled()) > return true;
I thought about this, but it means khugepaged is turned on regardless of anon and shmem configs. I tend to think the original code was a bug, since enabling CONFIG_READ_ONLY_THP_FOR_FS would enable khugepaged all the time. > > ... or maybe this whole thing could be simplified? Alternatives could be: 1. to add a file-backed khhugepaged config, but another sysfs? 2. to replace hugepage_pmd_enabled() with hugepage_global_enabled() and let thp_vma_allowable_order() in collapse_scan_mm_slot() skip not qualified VMAs, but that would waste extra CPU cycles for scanning. Maybe not too much waste. Best Regards, Yan, Zi
