Re: [PATCH v3 08/11] mm, swap: only charge physical swap entries

[Nhat Pham]

On Fri, Aug 7, 2026 at 9:31 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
>
> On Thu, Aug 06, 2026 at 11:42:51AM -0700, Nhat Pham wrote:
> > Charge memcg->swap when a vswap entry acquires physical backing rather
> > than when it is allocated, so memory.swap.current tracks on-disk swap
> > usage. Zswap-backed and zero-filled pages occupy no swap space but were
> > charged as though they did.
> >
> > memory.swap.current therefore no longer counts them, and a cgroup whose
> > pages all land in zswap can now reclaim anon memory with memory.swap.max
> > set to 0.
> >
> > Direct-mapped physical swap charging is unchanged.
> >
> > Signed-off-by: Nhat Pham <nphamcs@xxxxxxxxx>
>
> To head off any uncertainty about this: this is exactly what needs to
> happen in terms of cgroup semantics.
>
> memory.swap.* are about physical swap space. They track, control, and
> enforce fairness for a finite resource that is separate from memory.
>
> When a user switches on vswsap and a bunch of empty pages are stored
> inside the zeromap without consuming swapfile space, these counters
> must be 0.
>
> When a user switches on vswap to use zswap without a backing file,
> these counters must be 0.
>
> When a user switches on vswap to use zswap with writeback, only the
> pages that get written to the swapfile must be tracked and controlled
> by these counters.

I agree, and yeah I should have been clearer about the reasoning in
this patch commit message itself. I made the argument in a response to
Kairui's inquiry in the past, but forgot to include it here. My
apologies - will expand on this in the next version.

It really does not make sense to make zswap and phys swap competes for
the same limit, when they don't compete for a tangible resource (zswap
consumes memory, where as phys swap consumes storage space).

>
> A few inline comments on the implementation:

Acked. I'm trying to implement this. Will report back if something
doesn't work, but otherwise it will be in the next version.