On 23 Mar 2026, at 17:21, David Hildenbrand (Arm) wrote: > On 3/23/26 22:11, Zi Yan wrote: >> On 23 Mar 2026, at 17:05, David Hildenbrand (Arm) wrote: >> >>> On 3/23/26 22:02, Matthew Wilcox wrote: >>>> >>>> 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. >>> >>>> >>>> >>>> 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. > > At least not regarding adding support for other folio sizes. Baolin > (IIRC) had a version for shmem support, but that will come after Nico's > series was merged.
Great. That makes my life easier. Thanks. Best Regards, Yan, Zi
