On Mon, Apr 4, 2022 at 5:16 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Mon, Apr 04, 2022 at 01:02:42PM -0700, Yang Shi wrote: > > The readonly FS THP relies on khugepaged to collapse THP for suitable > > vmas. But it is kind of "random luck" for khugepaged to see the > > readonly FS vmas (see report: https://lore.kernel.org/linux-mm/00f195d4-d039-3cf2-d3a1-a2c88de397a0@xxxxxxx/) since currently the vmas are registered to khugepaged when: > > I still don't see the point. The effort should be put into > supporting large folios, not in making this hack work better. The series makes sense even though the hack is replaced by large folios IMHO. The problem is the file VMAs may be not registered by khugepaged consistently for some THP modes, for example, always, regardless of whether it's readonly or the hack is gone or not. IIUC even though the hack is replaced by the large folios, we still have khugepaged to collapse pmd-mappable huge pages for both anonymous vmas and file vmas, right? Or are you thinking about killing khugepaged soon with supporting large folios? Anyway it may make things clearer if the cover letter is rephrased to: When khugepaged collapses file THPs, its behavior is not consistent. It is kind of "random luck" for khugepaged to see the file vmas (see report: https://lore.kernel.org/linux-mm/00f195d4-d039-3cf2-d3a1-a2c88de397a0@xxxxxxx/) since currently the vmas are registered to khugepaged when: - Anon huge pmd page fault - VMA merge - MADV_HUGEPAGE - Shmem mmap If the above conditions are not met, even though khugepaged is enabled it won't see any file vma at all. MADV_HUGEPAGE could be specified explicitly to tell khugepaged to collapse this area, but when khugepaged mode is "always" it should scan suitable vmas as long as VM_NOHUGEPAGE is not set. So make sure file vmas are registered to khugepaged to make the behavior more consistent.
