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

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

On Wed, Jul 15, 2026 at 10:30:26AM -0700, Chris Li wrote:
> On Wed, Jul 15, 2026 at 9:27 AM Yosry Ahmed <yosry@kernel.org> wrote:
> >
> > On Tue, Jul 14, 2026 at 10:58 PM Youngjun Park <youngjun.park@lge.com> 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.

Yes please let's do this. Can you also please comment on Youngjun's response at
https://lore.kernel.org/all/alcebHobUCUyO70k@yjaykim-PowerEdge-T330/ as well?