Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs

[Usama Arif <usama.arif@linux.dev>]

On 13/06/2026 05:22, Lance Yang wrote:
> 
> On Wed, Jun 10, 2026 at 03:44:32PM +0100, Usama Arif wrote:
>>
>>
>> On 10/06/2026 14:48, David Hildenbrand (Arm) wrote:
>>> On 6/10/26 15:01, Lance Yang wrote:
>>>>
>>>>
>>>> On 2026/6/10 20:24, David Hildenbrand (Arm) wrote:
>>>>> On 6/9/26 16:29, Usama Arif wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Just following up if there were any reviews/comments on this series!
>>>>>>
>>>>>> I know its a large series but was just checking if there was any
>>>>>> feedback?
>>>>>
>>>>> It shall be reviewed. We just finished the mTHP khugepaged review to get it into
>>>>> 7.2, so we've all been rather busy.
>>>>
>>>> Right, mTHP khugepaged was a rough one. Glad we got it over the line,
>>>> but yeah, there's just been a lot of THP work lately. pretty nonstop ...
>>>>
>>
>> Yeah its definitely a lot. I have set a target of leaving review comments on
>> atleast 2 patches from mm per day myself, but even that can sometimes be
>> difficult! I will try and help out more in reviews.
> 
> Awesome!
> 
>>>>> (I mean, just take a look at the THP-related flood of patches we are fighting
>>>>> with on a daily basis, it's not funny anymore)
>>>>>
>>>>> This is clearly going to be 7.3 material, so there is plenty of time given that
>>>>> the merge window is about to open soon.
>>>>
>>>> Usama, I'll try to make this one a priority too. Looks interesting :P
>>
>> Thanks Lance!
>>
>>>
>>> I have two other bigger series to review, but I should soon get to this as well.
>>>
>>
>> No worries at all! Thanks for the reviews! and yeah definitely 7.3.
>>
>> I will send this out again when 7.3-rc1 opens (rebased), so that the reviews wont be on
>> outdated code which could cause some confusion.
> 
> After skimming through the whole series, probably PMD swap entries need
> one bigger rethink ...
> 
> Emm ... same tricky bit keeps showing up ...
> 
> One PMD swap entry is easy to handle while the swapcache still has one
> PMD-sized folio behind it. Once taht folio got split and reclaimed, the
> 512 swap slots need per-page handling :)
> 
> Maybe worth first pinning down the rule here.
> 
> Is a PMD swap entry supposed to mean "there is, or soon will be, one PMD-
> sized folio behnid it", or is just a compact page-table encoding for
> 512 swap slot?
> 
> Without that rule being very clear, every caller has to guess how much
> it can assume, and it is easy to miss one ...
> 
> So I stopped staring at the details for now, because the same issue keeps
> popping up wearing a slightly different hat :)
> 
> Anyway, no clever answer from me here, not a swap expect :( Just pointing
> out the pattern I keep runing into.
> 

Thanks for the amazing reviews!

For the next revision I’m going to treat a PMD swap entry as just a compact
page-table encoding for 512 ordinary swap slots. It does not mean that the
swapcache still has, or will soon have, one PMD-sized folio behind it.

With that rule, whole-PMD handling is only valid when either:

1. the swapcache still has one PMD-sized folio for the range, or
2. the whole PMD swap range has no cached folios, so the caller can try a
   PMD-sized swapin and still fall back if that is not possible.

If any slot in the range has per-page cache state, the PMD entry has to be
split and the existing PTE paths need to handle the individual slots.

I an reworking the next revision around that. I added a shared helper to
classify the swapcache behind a PMD swap entry as empty, PMD-sized, or
split, then used it in the places where this assumption mattered:
mincore, UFFDIO_MOVE, swapoff, MADV_WILLNEED, and the PMD swap fault path.
UFFDIO_MOVE now checks the whole 512-slot range before moving a PMD swap
entry without a cached folio, and falls back to PTE handling if per-page
cached folios exist.

Thanks!
Usama