Re: [RFC PATCH 4/5] mm: swap: fall back to order-0 after large swapin races

[Fujunjie <fujunjie1@qq.com>]

On 5/11/2026 10:59 PM, Kairui Song wrote:
> On Mon, May 11, 2026 at 9:14 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 5/8/26 22:20, fujunjie wrote:
>>> swapin_folio() documents that a large folio insertion race returns NULL
>>> so the caller can fall back to order-0 swapin. do_swap_page() currently
>>> turns that NULL into VM_FAULT_OOM if the PTE is unchanged, which is
>>> harsher than necessary and gets in the way of rejecting large folio
>>> ranges for backend reasons.
>>>
>>> Move the synchronous swapin sequence into a helper and retry with an
>>> order-0 folio when a large folio cannot be inserted into the swap cache.
>>> Count the event as an mTHP swapin fallback before dropping the failed
>>> large allocation.
>>>
>>> Signed-off-by: fujunjie <fujunjie1@qq.com>
>>> ---
>>>  mm/memory.c | 50 +++++++++++++++++++++++++++++++++++++++-----------
>>>  1 file changed, 39 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index ea6568571131..84e3b77b8293 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -4757,6 +4757,44 @@ static struct folio *alloc_swap_folio(struct vm_fault *vmf)
>>>  }
>>>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>>>
>>> +static struct folio *swapin_synchronous_folio(swp_entry_t entry,
>>> +                                           struct vm_fault *vmf)
>>> +{
>>> +     struct folio *swapcache, *folio;
>>> +     bool large;
>>> +     int order;
>>> +
>>> +     folio = alloc_swap_folio(vmf);
>>> +     if (!folio)
>>> +             return NULL;
>>> +
>>> +     large = folio_test_large(folio);
>>> +     order = folio_order(folio);
>>> +
>>> +     /*
>>> +      * folio is charged, so swapin can only fail due to raced swapin and
>>> +      * return NULL.
>>> +      */
>>> +     swapcache = swapin_folio(entry, folio);
>>> +     if (swapcache == folio)
>>> +             return folio;
>>> +
>>> +     if (!swapcache && large)
>>> +             count_mthp_stat(order, MTHP_STAT_SWPIN_FALLBACK);
>>> +     folio_put(folio);
>>> +     if (swapcache || !large)
>>> +             return swapcache;
>>> +
>>> +     folio = __alloc_swap_folio(vmf);
>>> +     if (!folio)
>>> +             return NULL;
>>> +
>>> +     swapcache = swapin_folio(entry, folio);
>>> +     if (swapcache != folio)
>>> +             folio_put(folio);
>>> +     return swapcache;
>>> +}
>>> +
>>>  /* Sanity check that a folio is fully exclusive */
>>>  static void check_swap_exclusive(struct folio *folio, swp_entry_t entry,
>>>                                unsigned int nr_pages)
>>> @@ -4860,17 +4898,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>               swap_update_readahead(folio, vma, vmf->address);
>>>       if (!folio) {
>>>               if (data_race(si->flags & SWP_SYNCHRONOUS_IO)) {
>>> -                     folio = alloc_swap_folio(vmf);
>>> -                     if (folio) {
>>> -                             /*
>>> -                              * folio is charged, so swapin can only fail due
>>> -                              * to raced swapin and return NULL.
>>> -                              */
>>> -                             swapcache = swapin_folio(entry, folio);
>>> -                             if (swapcache != folio)
>>> -                                     folio_put(folio);
>>> -                             folio = swapcache;
>>> -                     }
>>> +                     folio = swapin_synchronous_folio(entry, vmf);
>>>               } else {
>>>                       folio = swapin_readahead(entry, GFP_HIGHUSER_MOVABLE, vmf);
>>>               }
>>
>> There are some upcoming changes with:
>>
>> https://lore.kernel.org/r/20260421-swap-table-p4-v3-5-2f23759a76bc@tencent.com
>>
>>
>> All the of that logic you have in swapin_synchronous_folio() should ideally not
>> go into memory.c, but into some swap specific code.
>>
>> But
>>
>> https://lore.kernel.org/r/20260421-swap-table-p4-v3-0-2f23759a76bc@tencent.com
> 
> Thanks for mentioning this!
> 
> I think Junjie's change fits better after that change indeed. And I
> checked the code, it should fits easily too.
> 
> It's already strange enough that THP swapin is bundled with
> synchronous swapin, we better not make it more divergent here, and add
> more bits into memory.c.
> 
> And this commit will limit it to anon, no shmem, which is another
> strange detail. Or we'll have to repeat everything and copy these code
> to shmem.c...
> 
> Once all swap-ins uses basically the same path as in that series, all
> swap-ins will be able to have similar THP and zswap THP support too.

Thanks David and Kairui.

That makes sense. The helper in memory.c was mainly added to demonstrate
the fallback needed by this RFC, but I agree that growing more large-folio
swapin logic in the anon synchronous swapin path is not the right
direction.

I will not carry this patch forward in its current form. If I continue
with this work, I will rebase it on top of Kairui's swap-table or unified
swapin work and keep the allocation and fallback handling in the swap-specific
common path.

I also noticed Alexandre is already working on the large-folio swapin
side, so I will follow that series to avoid duplicating work.

Thanks for the pointers.