Re: [PATCH mm-new v9] mm: vmscan: retry folios written back while isolated for traditional LRU

[Ridong Chen <ridong.chen@linux.dev>]

On 9/17/2026 5:25 AM, Barry Song wrote:
> On Wed, Sep 16, 2026 at 8:39 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>
>> From: Ridong Chen <chenridong@xiaomi.com>
>>
>> As commit 359a5e1416ca ("mm: multi-gen LRU: retry folios written back
>> while isolated") mentioned:
>>
>>    The page reclaim isolates a batch of folios from the tail of one of the
>>    LRU lists and works on those folios one by one.  For a suitable
>>    swap-backed folio, if the swap device is async, it queues that folio for
>>    writeback.  After the page reclaim finishes an entire batch, it puts back
>>    the folios it queued for writeback to the head of the original LRU list.
>>
>>    In the meantime, the page writeback flushes the queued folios also by
>>    batches.  Its batching logic is independent from that of the page
>>    reclaim. For each of the folios it writes back, the page writeback calls
>>    folio_rotate_reclaimable() which tries to rotate a folio to the tail.
>>
>>    folio_rotate_reclaimable() only works for a folio after the page reclaim
>>    has put it back.  If an async swap device is fast enough, the page
>>    writeback can finish with that folio while the page reclaim is still
>>    working on the rest of the batch containing it.  In this case, that folio
>>    will remain at the head and the page reclaim will not retry it before
>>    reaching there".
>>
>> The commit 359a5e1416ca ("mm: multi-gen LRU: retry folios written back
>> while isolated") only fixed the issue for mglru. However, this issue
>> also exists in the traditional active/inactive LRU and was found at [1].
>>
>> It can be reproduced with below steps [3]:
>>
>> 1. Compile with CONFIG_TRANSPARENT_HUGEPAGE=y
>> 2. Mount memcg v1, and create memcg named test_memcg and set
>>     limit_in_bytes=1G, memsw.limit_in_bytes=2G.
>> 3. Create a 1G swap file, and allocate 1.35G anon memory in test_memcg.
>>
>> It was found that:
>>
>>    cat memory.usage_in_bytes
>>    1073700864
>>    cat memory.memsw.usage_in_bytes
>>    1413124096
>>
>>    free -h
>>                  total        used        free
>>    Mem:           1.6Gi       1.2Gi       299Mi
>>    Swap:          1.0Gi       678Mi       346Mi
>>
>> As shown above, the test_memcg charged about 324M swap (memsw.usage minus
>> usage), but almost 678M swap memory was used, which means that 350M+ may
>> be wasted because other memcgs can not use these swap memory.
> 

Thank you for your review.

> I don't like the way you describe the problem as "wasted" swap.
> 
> The real problem is that those folios skipped
> `folio_rotate_reclaimable()`, so they were added back to the head
> instead of the tail, where rotation could have moved them to the tail.
> This resulted in a cold/hot inversion.
> 
> The swap entries they are using now will eventually be released when
> we scan those folios again and reach the head of the list, so this is
> not actually wasted swap space. You are probably right, on the other
> hand, that if those head folios hold swap entries and the swap is
> full, this could prevent the reclamation of folios at the tail, making
> it even harder for us to reach the head.
> 

This issue was observed with unexpected OOM. For example, Docker A swapped out 2 
GB, but it held more than 8.5 GB of swap on the host. Those 6.5 GB could not be 
used by other Docker containers, which could trigger OOM. So it seems the swap 
was "wasted." After all, it is a global resource, yet it was held for a private 
cgroup even though that cgroup did not need so much swap.

>>
>> This issue should be fixed in the same way as mglru. Therefore, the common
>> logic was extracted to the 'find_folios_written_back' function firstly,
>> which is then reused in the 'shrink_inactive_list' function. Finally,
>> retry reclaiming those folios that may have missed the rotation for
>> traditional LRU.
> 
> I wouldn't necessarily call it a fix, as keeping the swap cache for
> those folios can sometimes help with future hits. For example, we may
> hit those folios again before they are reclaimed. So it's a
> double-edged sword.
> 
> That said, the cold/hot inversion is a real problem that we should
> fix. Ideally, we should find a way to restore the missed
> `folio_rotate_reclaimable()` behavior, conceptually something like:
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fde28d0a647d..5ee296474b48 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -891,7 +891,10 @@ long remove_mapping(struct address_space
> *mapping, struct folio *folio)
>    */
>   void folio_putback_lru(struct folio *folio)
>   {
> -       folio_add_lru(folio);
> +       if (folio_has_been_writtenback_due_reclaim(folio))
> +               folio_add_lru_tail(folio);
> +       else
> +               folio_add_lru(folio);
>          folio_put(folio);               /* drop ref from isolate */
>   }
> 

That is a good idea. But I am not sure I can find the correct way to do it. I 
will give it a try and get back to you.

> But if that turns out to be impossible or practically infeasible,
> leveraging MGLRU's approach could still be a possible workaround, as
> it would at least be better than the current behavior.
> 
> On the other hand, the fast swap-out cases should be similar to zram
> and zswap, as Yu Zhao mentioned in his previous commit:
> 
> "This problem affects relatively slow async swap devices like
> Samsung 980 Pro much less and does not affect sync swap devices like
> zram or zswap at all."
> 
>>
>> After change, the same test case only wasted about 2M swap. The swap
>> device usage matches what the memcg actually charged.
>>
>>    cat memory.usage_in_bytes
>>    1070301184
>>    cat memory.memsw.usage_in_bytes
>>    1412448256
>>
>>    free -h
>>                  total        used        free
>>    Mem:           1.6Gi       1.2Gi       299Mi
>>    Swap:          1.0Gi       327Mi       696Mi
>>
>> [1] https://lore.kernel.org/linux-kernel/20241010081802.290893-1-chenridong@huaweicloud.com/
>> [2] https://lore.kernel.org/linux-kernel/CAGsJ_4zqL8ZHNRZ44o_CC69kE7DBVXvbZfvmQxMGiFqRxqHQdA@mail.gmail.com/
>> [3] https://lore.kernel.org/lkml/46037a37-4cf6-448e-a94b-30a4d16e8814@linux.dev/
>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
>> ---
> 
> Thanks
> Barry

-- 
Best regards
Ridong