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

[Youngjun Park <youngjun.park@lge.com>]

On Wed, Jul 15, 2026 at 01:35:56PM -0700, Shakeel Butt wrote:
> 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?

Hi Shakeel, Chris, and Yosry,

Thanks for the review and replies. It seems we have reached a consensus.

In the next patch series, I will update the swap.tiers.max interface to
allow controlling zswap with 0 or max.

Internally, I will handle it as a not perfect tier. 
Anyway since the user-visible interface is designed with future zswap tiering in mind, 
this approach naturally accommodates future zswap tier integration, while remaining easy to drop 
to make it as a tier if it proves unpromising (remaining this interface only controls zswap on/off).

As a follow-up, we can continue discussing the tiering of zswap, vswap,
Xswap, and ghostswap. If we proceed, making zswap an actual logical tier
entity and organizing its relationship with other interfaces (i.e., complete
tiering) will be deferred to a future patchset.

I will keep you updated if further discussion is needed during implementation.
Please let me know if you have any other feedback!

Thanks,
Youngjun