Re: [PATCH v10 0/6] mm/swap, memcg: Introduce swap tiers for cgroup based swap control

[Chris Li]

On Mon, Jul 13, 2026 at 11:38 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> > > > Zswap will not be introduced as a tier. The existing user interface
> > > > makes zswap not exactly compatible with the tier ordering because it
> > > > sits in front of every swapfile. If we change that, we break the user
> > > > interface. I suggest we keep zswap working as it is now.
> > >
> > > The goal from making zswap a swap tier is to have a single framework
> > > to configure swapping for a cgroup, instead of configuring zswap
> > > separately. Yes, zswap currently sits in front of all swap
> > > devices/tiers, but we are heading in the direction of changing that
> > > such that zswap is standalone, at which point it becomes more
> > > obviously a swap tier. If you want us to wait until that happens
> > > before adding zswap as a tier, I don't necessarily object, but I want
> > > to make sure that nothing will break if we add zswap as a tier later.
> >
> > I'm afraid your zswap user interface will have to break. I don't see a
> > way around breaking your zswap user interface to fit the swap tiering.
> > Once we move to the swap tier world, I don't think we should continue
> > using zswap.writeback to control the tier write back behavior. We will
> > need to rethink this new world.
>
> I wasn't talking about the existing zswap interfaces. I want to make
> sure that if we introduce tiering initially without zswap as a tier,
> then add zswap as a tier, the semantics of tiering and user-visible
> zswap behavior doesn't break.

No, the user visible part of zswap must break because zswap currently
sits in front of every swapfile.
I don't see any other way around it.

If you do know how zswap can interact with swap.tiers without breaking
the user interface, make a formal proposal and lay out all the
details. I did that exercise myself and I my conclusion is that it is
better to accept zswap is the classic behavior without burdening the
unified swap tier too much.

> That being said, the existing zswap interfaces don't have to break
> with tiering, why do they? We may end up with redundant interfaces,

Because zswap does not have its own swap device, it borrows the swap
slot from the underlying swap device. That behavior is unique to zswap
and none of the other swap tiers have that.

> which is unfortunate, and we can work to deprecate some of them over
> time. But I don't see why we have to break them?

I don't want to special case the zswap for from the swap tiers.

> > > An advantage of adding zswap as a tier right away is the proactive
> > > writeback use case. It naturally fits in the tiering framework as
> > > proactive demotion between swap tiers, which I expect may be useful in
> > > non-zswap use cases as well. Without zswap as a tier, we'll have to
> > > use a different interface for proactive writeback, and then if/when
> > > zswap becomes a tier, we'll have multiple ways to do proactive
> > > writeback which isn't ideal.
> >
> > I am looking forward to abstracting a more common write back behavior
> > in the swap tier world. The classic zswap behavior will be preserved.
>
> Right, but this requires zswap being a tier, which you seem to be opposed to :)

It does not need to as far as I can tell. People who want classic
zswap can use zswap as it is. I am thinking the swap ops provide some
interface for classic zswap to use, but zswap itself is not a tier
because it does not own swap devices.

Chris