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

On Tue, Jul 14, 2026 at 10:58 PM Youngjun Park <[email protected]> wrote:
>
> On Tue, Jul 14, 2026 at 03:25:40PM -0700, Shakeel Butt wrote:
> > 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.
>
> Maybe we can handle zswap as an internally reserved tier which is always
> preferred over swap devices.
>
> I do not think there is a strong use case for grouping zswap together with a
> swap device that happens to use the highest priority. Also, using a visible
> priority value for zswap may have a small side effect that one priority value
> effectively becomes unavailable to users.
>
> That said, if zswap is represented as a tier, I agree that it should be the
> top tier. The exact priority value or whether it is internally reserved should
> be adjustable when we implement it.

Agreed.

[..]
> I agree this is reasonable. I can treat the demotion/writeback interaction as
> future work and follow up separately.
>
> > Youngjun, what do you think? Is this reasonable amount of additional work or do
> > you envision some complexity here?
>
> I sent a note with some thoughts about making zswap a tier. Since Chris also
> raised concerns around this area, I think it would be better to discuss it a
> bit more and evaluate the details carefully.
>
> At this point, there does not seem to be an immediate use case that requires
> zswap tiering in this series. So my preference is to keep this as future work
> for now, and follow up with an RFC after verifying that introducing zswap as a
> tier on top of this patchset does not cause problems.

My main concern is locking ourselves into an implementation without
zswap as a tier. One of the appeals of swap tiering to me, from the
zswap side, is eventually unifying zswap writeback as part of a more
general swap demotion, and unifying zswap controls with more general
swap tier controls.