Re: [PATCH mm-new v1 2/2] mm: vmscan: skip anon folios zswap would refuse when writeback is off

[Jiayuan Chen]

On 10/31/26 6:32 AM, Yosry Ahmed wrote:
> On Sat, Oct 31, 2026 at 03:03:26AM +0800, Barry Song wrote:
>> On Sat, Oct 31, 2026 at 1:52 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>>> On Fri, Oct 30, 2026 at 2:53 AM Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
>>>> A memcg with memory.zswap.writeback=0 can only swap into zswap. Once
>>>> zswap stops taking its pages, because the pool is at its limit or the
>>>> memcg is at memory.zswap.max, swap_writeout() has nowhere to put a
>>>> dirty folio and returns AOP_WRITEPAGE_ACTIVATE.
>>>>
>>>> shrink_folio_list() only learns that at the very end. Every folio it
>>>> picks gets a swap slot, is unmapped, fails in swap_writeout() and goes
>>>> back to the active list, to be aged and tried again. Each round costs
>>>> a slot, an rmap walk, a TLB flush and a minor fault for the owner, and
>>>> frees nothing. The folio also stays in the swap cache holding its slot.
>>>>
>>>> The obvious place for a zswap check is can_reclaim_anon_pages(), but
>>>> it cannot go there. Zero-filled folios never reach zswap:
>>>> swap_writeout() marks them in the swap table and returns before
>>>> zswap_store() is called. They need no pool space, they are common, and
>>>> a memcg-wide "no anon" decision would keep them in memory for as long
>>>> as zswap is full. With zswap full they must still be reclaimable.
>>> I really wonder if we should revisit not swapping zero-filled pages at
>>> all, and instead mapping them to the zero page read-only (and whatever
>>> the equivalent for shmem could be), because yes, the right place is
>>> can_reclaim_anon_pages(). I don't remember what happened to that
>>> proposal, Usama do you remember?
>> Hi Yosry,
>>
>> FYI, I recalled that we discussed something similar in this
>> thread too:
>> https://lore.kernel.org/linux-mm/20241212073711.82300-1-21cnbao@xxxxxxxxx/
>>
>> It would be nice to see an implementation that maps
>> zero-filled pages to the shared zero page.
> Yeah I also found Usama's attempt and the complication that were found,
> unfortunately it's not simple:
>
> https://lore.kernel.org/linux-mm/20240604105950.1134192-1-usamaarif642@xxxxxxxxx/.



Exactly, it is complicated.
Taking zero-filled pages out of the swap path doesn't look like an
easy thing to do.