On 23 Mar 2026, at 17:05, David Hildenbrand (Arm) wrote: > On 3/23/26 22:02, Matthew Wilcox wrote: >> On Mon, Mar 23, 2026 at 04:24:26PM -0400, Zi Yan wrote: >>> On 23 Mar 2026, at 16:13, David Hildenbrand (Arm) wrote: >>>> I assume so, because for executables you would have to be lucky to get a >>>> PMD THP? So I don't see the non-khugepaged large folio support on par >>>> with khugepaged support. >> >> Not necessarily that lucky; if you set VM_HUGEPAGE, >> do_sync_mmap_readahead() will allocate PMD-sized folios automatically. >> On busy database servers (and is there any other kind?), khugepaged >> takes too long to run and find opportunities to collapse text pages. >> Like, days. > > Yes, in particular given that the default khugepaged settings are awful. > >> >>> It is more like turning on READ_ONLY_THP_FOR_FS by default for >>> FS with large folio support instead of removing it. >>> >>> OK, I will give it another try. >> >> I think the test needs to be: >> >> if (mapping_max_folio_order(mapping) >= PMD_ORDER)
This is very helpful, since I was thinking about using mapping_large_folio_support(). >> >> as there can be cases of filesystems which support up to, say, 64KiB, >> but not all the way up to 2MiB. I disapprove of this situation, but >> this is where we are right now. > > Right, that's what I had in mind. Does Nico’s mTHP support for khugepaged include changes to collapse_file()? That might change the above test. Best Regards, Yan, Zi
