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

[Yosry Ahmed]

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/.