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

On Sat, Jul 18, 2026 at 8:11 AM Youngjun Park <[email protected]> wrote:
>
> I tried to forbid this at the implementation level as you suggested
> , and that is where I ran into trouble.
> A few code paths can end up with zswap as the only
> tier, and they are awkward to handle.  Below is each case and what
> handling it would take:
>
> 1) A write turns off the last device tier while zswap stays on.
>    -> rejected with -EINVAL.  The write does not take effect.
>
> 2) The last device tier is removed via /sys/kernel/mm/swap/tiers.
>    -> the file goes empty, so zswap is not shown either.
>
> 3) A cgroup has zswap and one device tier on, and that tier is removed.
>    -> the cgroup's zswap entry is reset to 0, which the user never
>       asked for.
>
> 4) A cgroup has zswap and device tiers on, and swapoff empties them.
>    -> the cgroup's zswap entry is reset to 0.
>
> So the problem is that in (3) and (4), memory.swap.tiers.max has to
> change on its own independently of what the user wrote
> and it is not like just error handling situation as (1).

This kind of complexity is exactly the reason I object to having zswap
as a tier in the first place. There is very little gain in having such
control for zswap in the swap tier world and it introduces a lot of
corner-case complexity.

In my mind, we should introduce a separate swap tier native memory
tier. e.g. xswap. which has a clean conceptual break from zswap
(though code can be shared). The xswap will behave like zram in terms
of tiering, but be more integrated with MM like zswap.

I think the simplest answer is just to allow zswap as a special tier,
meaning it only has an on/off control on the side. Allowing zswap as
the only tier means the cgroup won't be able to use zswap because
there are no real devices.

> There is also a consistency point.  memory.swap.tiers.max already
> accepts a child enabling a tier that its parent has disabled: the write
> succeeds, no error is returned, and the difference is resolved
> internally.  The user's setting is kept as written, and only the
> effective behavior is constrained.  By that logic, accepting a
> zswap-only setting and guaranteeing only that it cannot do anything
> would fit how the interface already behaves.
>
> Having thought it over, I think one of these two directions would be
> better than enforcing the rule as above.
>
> 1. Allow zswap-only in memory.swap.tiers.max.  As you say, it cannot
>    work without vswap, so today the setting does nothing and there is
>    nothing to prevent.  Once vswap/xswap lands it becomes meaningful on its
>    own, with no interface change needed.

Allow it on paper and accept that zswap is not a real tier. It is just
a cache in front of other swap devices.
That is what I think as well.

>
> 2. Expose memory.swap.tiers.max.effective, like cpuset.  We already
>    track the user-set and the effective-set separately.  Exposing
>    the effective one would show that a zswap-only setting is not in
>    effect, giving the user visibility instead of rewriting what they
>    wrote.  It would also help the parent-off/child-on case, where the
>    child could see from the effective value that the tier is off.

Seems more complex than it is worth.

Chris

>
> What do you think? or any other ideas?
>
> Thanks,
> Youngjun
>