Re: [PATCH v2 4/4] mm: try to free swapcache for non-LRU folios

[David Hildenbrand (Arm)]

On 7/1/26 11:50, Barry Song wrote:
> On Wed, Jul 1, 2026 at 4:18 PM David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> [...]
>>>
>>> The newly allocated folio will likely still be sitting in this
>>> CPU's local LRU cache. If we drop the drain in patch 1, it seems
>>> there is little point in calling do_wp_page() from
>>> do_swap_page(), since we won't be able to reuse the folio while
>>> it remains in the local LRU cache.
>>
>> Well, we call do_wp_page() here to avoid another page fault where we would end
>> up in do_wp_page() and actually break COW.
> 
> Yep. We still need do_wp_page() to handle CoW, but we could
> actually reuse the folio if we don't drop the LRU drain.
> 
>>
>>>
>>> So I'm wondering whether we should keep the drain in
>>> patch 1 by checking for a refcount of 3, or instead do
>>> something like the following in patch 4:
>>>
>>>
>>>         if ((vmf->flags & FAULT_FLAG_WRITE) && !pte_write(pte)) {
>>>                  lru_add_drain();
>>>                  ret |= do_wp_page(vmf);
>>>                  if (ret & VM_FAULT_ERROR)
>>>                          ret &= VM_FAULT_ERROR;
>>>        }
>>>
>>> Otherwise, the combination of patches 1 and 4 seems somewhat
>>> inconsistent. It feels like a strange mix of sweet, spicy,
>>> hot, and cold—kind of contradictory :-)
>>
>> Yes, this needs a proper thought.
>>
>> What you describe is relevant for
>>
>> e.g.,
>>
>> swapout
>> fork -> exclusive bit cleared
>> child exit -> parent is single user
>> swapin -> added to swapcache and LRU cache
>>
>>
>> This is not very odd, so we should keep that working (I think I have
>> micro-benchmarks for that).
> 
> Maybe the simplest approach is to keep the drain in patch 1 and
> just make the code improvements you suggested in [1]?

Yeah, probably best for that scenario.

-- 
Cheers,

David