On 3/24/26 8:12 AM, Zi Yan wrote:
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.
Right. Here is the link to the RFC version:
https://lore.kernel.org/all/[email protected]/
Moreover, I have further updated my local tree based on Nico's series. I
will send out the new version once his series is merged.
