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

[Shakeel Butt <shakeel.butt@linux.dev>]

On Tue, Jul 14, 2026 at 01:52:14PM -0700, Yosry Ahmed wrote:
[...]
> >
> > Yosry, what is needed to enable zswap as a swap tier? What will be the minimum
> > requirements for that?
> 
> From zswap's perspective, we just need to skip zswap is zswap as a
> tier is disallowed. Could just be a check in zswap_store() similar to
> the check if zswap is enabled. I am assuming that if a swap tier is
> disabled, nothing happens to the existing swapped out pages in this
> tier, but new pages do not get swapped out to it. This is the same
> behavior that happens if zswap is disabled at runtime.
> 
> From the tiering perspective, we need to accept "zswap" as a possible
> tier, or maybe creating it as a tier by default if zswap is configured
> would be better to avoid handling the case where the user doesn't
> create a tier for zswap. 

Default tier if zswap is configured makes sense. Should zswap be treated as
having 32767 (or maybe 32768) as priority as it sits infront of all swap
devices today? Also whichever swap tier has priority range containing 32767,
will have zswap in it.

> We also need to disallow zswap being the only
> tier as that combination cannot work without vswap.

Do we need to do anything explicitly for this? I am assuming in a kernel with
swap tier support, there always exist a swap tier if there is even a single swap
device configured i.e. a tier with the full priority range.

> 
> I think this should be enough to support "zswap" as a tier and allow
> disabling/enabling zswap per-memcg (or globally?) through tiering.
> 
> In the future, if/when swap demotion is added, we need to figure out
> how that would work with zswap. For example, if pages should go to
> swap device A then swap device B, then an entry in zswap using a swap
> slot in device B should not skip device A and be written back directly
> to B. vswap would naturally give us a solution for this problem.

This seems reasonable to me. Punting demotion/writeback to future.

Youngjun, what do you think? Is this reasonable amount of additional work or do
you envision some complexity here?

> 
> > If that is not too much, we can make that part of this series.
> 
> Yeah I think it's better if we agree on the design and zswap support
> before landing partial support.