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

[Yosry Ahmed]

On Mon, Jul 13, 2026 at 12:39 PM Chris Li <chrisl@xxxxxxxxxx> wrote:
>
> 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 zswap becomes usable independent from a swapfile, it's mostly
transparent to current users.

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

Today pages go to zswap, and when the limit is hit they get written
back to a swap device. If zswap is a separate tier, pages will still
go to zswap and then when the limit is hit they get written back to a
swap device. In both cases, zswap writeback can be disabled.

Can you share the findings from your exercise, and why zswap being a
tier is a burden? Any specific examples?

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

Yes, but we are heading in the direction of removing that restriction.
But I also don't see the connection between that and the current
interfaces breaking. Do you have any concrete examples?

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

Neither do I, but I fail to see where the special casing is, beyond
the fact that zswap is not a swapfile but an in-memory swap.

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

A swap tier represents a class of swap devices or swap files with
specific characteristics. Zswap satisfies that, although it's not
really a swap device/file.