Re: [PATCH v8 00/30] mm: PMD-level swap entries for anonymous THPs
From: Zi Yan
Date: Fri Oct 02 2026 - 11:17:50 EST
On 2 Oct 2026, at 10:28, David Hildenbrand (Arm) wrote:
> On 10/2/26 11:52, Usama Arif wrote:
>> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is
>> split into HPAGE_PMD_NR PTE-level swap entries via TTU_SPLIT_HUGE_PMD
>> before unmap. This series introduces a PMD-level swap entry so the
>> huge mapping can survive the swap round-trip and do_huge_pmd_swap_page()
>> can restore the PMD mapping directly on swap-in, without waiting for
>> khugepaged to collapse the range later.
>>
>> The PMD swap entry is a compact page-table encoding for HPAGE_PMD_NR
>> consecutive swap slots. swap_map accounting remains per-slot and is
>> unchanged. Importantly, a PMD swap entry does not promise that the swap
>> cache always contains one PMD-sized folio. While the cache is empty or
>> contains one PMD-sized folio, PMD-level handling can proceed. Once the
>> cache has split/per-slot state, users either inspect the individual
>> slots directly (mincore) or split the PMD swap entry and retry through
>> the PTE path (fault, swapoff, MADV_WILLNEED, UFFDIO_MOVE). MADV_FREE
>> does not consult the cache at all: it frees a whole PMD swap entry in
>> place and only splits when the advised range covers part of the PMD.
>> Likewise, if any slot is still backed by zswap's per-page
>> store, PMD-order swap-in consumers split and let the PTE path load the
>> range page by page; an all-on-disk range can still be read back as one
>> PMD-sized folio.
>>
>> The series is ordered so every consumer can handle PMD swap entries
>> before the swap-out producer starts installing them. The swap-out patch
>> is the last functional change.
>>
<snip>
>
> I was hoping that we could get this into the next merge window, but as we are
> approach rc6 and I didn't even manage to review all patches (shame on me), I
> assume this would be a quite fit.
>
> So I assume this series is one of the things that we'll try to get in shape over
> the next merge window to queue it early after rc1.
I am going to review this series, since I have done with Lorenzo’s VM_SPECIAL one.
Best Regards,
Yan, Zi