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

From: Barry Song

Date: Fri Oct 30 2026 - 15:05:08 EST


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.

Best,
Barry