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. -- Cheers, David
