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

On Wed, Jul 15, 2026 at 9:27 AM Yosry Ahmed <[email protected]> wrote:
>
> 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.

There is nothing locked. The major complexity will come when
zswap/vswap/Xswap/ghostswap become independent swap devices for swap
tiers. We are not there yet. But if you want a bool for zswap in swap
tiers world, we can make it happen trivially.

Chris