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

[Chris Li]

On Mon, Jul 13, 2026 at 10:11 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Mon, Jul 13, 2026 at 10:03 AM Chris Li <chrisl@xxxxxxxxxx> wrote:
> >
> > On Mon, Jul 13, 2026 at 9:01 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > > > My plan is to land the swap tier infrastructure together with the
> > > > first use case (cgroup-based swap control) first, and then follow
> > > > up with zswap tier support in a subsequent series, continuing the
> > > > discussions we've had above.
> > > > (I mentioned on cover letter, right above the overview section)
> > > >
> > > > Does that approach sound reasonable to you?
> > >
> > > How does swap tiering work with zswap in the current series? I assume
> > > zswap is just enabled for all devices in all tiers? I wonder if
> >
> > Zswap is not part of the tiers exactly because it sits in front of all
> > swap devices (tiers) and uses a different control to enable or disable
> > it.
> > Let's not combine these two; let zswap use its own existing cgroup
> > control interface.
> >
> > > introducing zswap as a tier after the fact changes user-visible
> > > behavior. I guess if zswap will be introduced with a default "max"
> > > value it will more-or-less be the same behavior, but I would check all
> > > user-visible behaviors related to zswap (e.g. interaction with other
> > > zswap interfaces) to make sure nothing breaks or changes in a
> > > meaningful way when zswap is introduced as a tier later.
> >
> > 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.

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

Chris