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

[Chris Li]

On Tue, Jul 14, 2026 at 10:58 PM Youngjun Park <youngjun.park@xxxxxxx> 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.

See my other email. Zswap shouldn't even be in the list of swap tiers
to search for swap slots, so this priority is builtin we don't need to
specify it.

> 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.

Just leave it alone and the order will happen naturally.

> > > 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.
>
> 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.

The minimal change is just giving zswap a bool to enable it in a swap
tier or not. Personally I don't think it is needed. But if others want
it we can add it as one off thing.

Chris