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 22, 2026 at 09:14:10AM -0400, Johannes Weiner wrote:

Hello Johannes!

> Zswap is a first-order swap destination with writeback semantics. The
> way the discussion around zswap has been going in this thread is
> disappointing, and I don't feel comfortable adding permanent user
> interfaces on this basis.

I have given this a lot of thought. First, could you clarify exactly which
part of the discussion or consensus makes you hesitate? Understanding this
will help me re-evaluate my proposal.

To make sure we are on the same page, I would like to share my thoughts and
vision for the present and future of the tier interface semantics for your
further consideration.

The interface should provide the swap amount allocated to a tier and allow
the use of the swap device defined by that tier via swap.tiers.max.
Currently, it would only support 0 and 'max' (essentially on/off for
explicit usage). Auto-demotion is planned for the future, and specifying
exact capacity limits is still to be determined. (I have also reviewed
potential interface collisions and duplications based on Yosry's guidance.)

From this perspective, zswap currently cannot exist as a standalone tier. It
resides in RAM when allocated and borrows slots from other swap devices.
(If all tiers except zswap are turned off, it is effectively the same as
zswap being off, meaning there is no zswap-only tier.) The zswap writeback
interface essentially leaves only the zswap first tier enabled by using
other swap slots. Virtualized swap should solve this in the near future.

On the other hand, in systems without zswap (like ours), this situation does
not occur. Allocation and deallocation depend strictly on swap priority,
avoiding this contradiction. (While it might be possible to implement the
tier interface only for !CONFIG_ZSWAP first, I abandoned this idea as it
seemed unpromising.)

In my initial review, I considered creating the swap tier interface while
excluding zswap configurations, even if zswap is present. From zswap's
perspective, it acts as a first-order swap, and other tiers operate well
according to their original tier semantics. Once virtualized swap arrives, we can
open up the interface without any contradictions.

However, virtualized swap might be toggled on or off (at runtime or
compile time), we must still account for zswap without virtualized swap anyway.
There is also a possibility that the initial overall picture might seem
misaligned until zswap tiering is officially introduced. It looks like we must
care this case on the first stage.

Therefore, I decided to follow Yosry's suggestion. Since a zswap-only setup
has contradictions, we initially considered removing user visibility
as possible as we can (returning an error for unsupported interfaces).

Because the implementation is a bit tricky, we agreed on an on/off toggle
for this first baby step, accompanied by detailed documentation so users are
fully aware of what a zswap-only tier means.

As a result, I reviewed this direction and found it does not conflict with a
future zswap tier. When virtualized swap arrives, the design will align
perfectly, and we can consider making zswap a proper tier.

One thing that remains undecided, however, is zswap tiering, which is not
yet fully agreed upon by everyone and should be discussed at the next stage.

> We will not be merging a memcg swap tier interface until the swap side
> has a story for indirection and backend migration.

Regarding this point, is your position that an indirect layer (I see
this is virtualized swap) must be implemented first?
Or do you mean we need community consensus on the overall design before proceeding?
I believe our direction is set toward virtualized swap, but there are still some discussions regarding
implementation details.

I would love to hear your thoughts. In the meantime, my preference is to
proceed as discussed if we can agree on the future direction. If more
discussion and design verification are needed, I am happy to follow up and
address any concerns you might have.

However, if you feel the tier concept is premature, I would like to hear
your thoughts and others' as well on a fallback option. We could add
per-cgroup swap control in debugfs for now. If we need to scale back, we
could either keep the swap tier design internally or drop it entirely,
implementing per-swap control strictly for our specific use case. We could
then revisit this as a primary use case when swap tier discussions resume.

What do you think? I would appreciate hearing everyone's thoughts on this.

Youngjun