Re: [swap tier discussion] Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback

[YoungJun Park <youngjun.park@lge.com>]

On Mon, Jun 15, 2026 at 12:55:09PM -0700, Yosry Ahmed wrote:
> > In that case, the internal logic could stay roughly the same rather
> > than counting via a page counter. Something like:
> >
> > 1. Change the interface shell: tier.*.max — allow only 0 ~ max.
> 
> What about a single interface as I suggested to remain consistent with
> memory tiering?

Hello Yosry!

I agree. As I was implementing the interface for seeing feasibility
, I reconsidered it. Since swap tiers can be added or removed at runtime, 
having static memory."tier_name".max files seems unnatural.

A single interface like `swap.tiers.max` would be better. We can use a
flat-keyed format (similar to io.weight. same as you suggested)

echo ["tier_name"] ["0 or max"] > swap.tiers.max

I am now leaning towards this is a better direction than what I initially
suggested (memory.swap.tiers and memory.swap.tiers.effective).

Considering other reviews and Shakeel's reply, I will update my swap tier
patch accordingly.

> > 2. Keep the internal logic as is: 0 disables the mask (child memcgs
> >    off too), max enables it (child memcgs on too).
> 
> I think a child should be able to disable a swap tier enabled by the
> parent, but not vice versa.

Yes, we are on the same page. I missed a part in my explanation. I meant
that the child's selected tiers should be a subset of the parent's (which
is how the current swap tier suggestion works). 
A child cannot enable a tier that the parent has disabled.

> > 3. memory.zswap.max integrates naturally (it's memory."tier_name".max).
> 
> Not really. memory.zswap.max is in terms of memory usage (compressed
> size), not swap usage (uncompressed size).

I see, memory.zswap.max needs to be maintained separately. I will look
closer into its semantics. I might have misunderstood this part!

> [..]
> > Let me clarify a part I wrote confusingly. Handling
> > memory.zswap.writeback via tiers is possible, but I don't think the
> > interface itself would be replaced even if memory.swap.tiers is adopted.
> >
> > Selecting only zswap in memory.swap.tiers would not just disable
> > writeback.it would also block regular swap entirely, which differs
> > slightly from the current semantic. (... "Per the cgroup v2 docs: a
> > zswap-only tier setting is subtly different from setting
> > memory.swap.max to 0, since it still allows pages to be written to the
> > zswap pool; this has no effect if zswap is disabled, and swapping is
> > allowed unless memory.swap.max is set to 0.")
> 
> I don't understand. How is disabling zswap writeback not equivalent to
> only enabling zswap as a tier?

Isn't there a case where zswap_store() fails and pages fall back to the
backing swap device?

- "zswap tier only": Only zswap is allowed. Fallback to other swap is
  blocked.
- "zswap writeback disabled": zswap is allowed, but if zswap_store()
  fails, pages can still fall back to other swap devices.

Because of this slight semantic difference, I thought they couldn't be
fully unified. If my understanding is correct, we could extend the zswap
tier to select the target swap device for writeback, but replacing the
writeback interface entirely might be difficult.

> Do you just mean the fact that disabling zswap writeback is a noop of
> zswap is disabled? It's a different interface so I think a small

Yes, I think so too.

> semantic difference is okay. In practice, I doubt that zswap is being
> disabled at runtime.

I thought disabling zswap at runtime might have some use cases, but we
can discuss this further when we talk about the patch extending the
zswap tier.

Best regards,
Youngjun