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

[Chris Li]

On Mon, Jul 13, 2026 at 12:57 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> 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?

It is all good when you have only zswap and just one other tier of swap device.
As soon as you add one more, e.g. zswap -> SSD -> HDD will make things
complicate when zswap using the HDD slot write back direclty to HDD.
Anyway, I find that this kind of highlevel hand waving discussion of
pros and cons usually doesn't produce the useful outcome. If you have
a detailed solution for how zswap works with multiple layers of swap
tiers, Laying out all the details and even better, providing some
incremental patches, is the better way to proceed.

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

See above. This topic has already seen a lot of heated discussion.
Show me an incrementally mergeable patch; that would be a better way
to move forward.

Chris