This is the v10 series of the swap tier patchset.

v10 folds in the Sashiko review fixes for the selftests added in v9 and
rebases onto the current mm-new. There are no functional changes to the
core swap or memcg code since v9; see the changelog for details.

For context, the bulk of the series is unchanged since v8, with great thanks
to Shakeel Butt and Yosry for the reviews and discussions [1] that shaped it.
The main change in v8 was the interface change to use memory.swap.tiers.max
with '0' (disable) and 'max' (enable) values. This mechanism was suggested
by Shakeel and Yosry.

This change allows for future extensions to control swap between tiers and
aligns better with existing memcg interfaces. It is confined to patch #3's
user-facing interface; internally, patch #3 still uses the existing mask
processing method, which is implementation-efficient.

We also discussed tier extensions. Thanks to Yosry, Nhat and Shakeel for their
valuable feedback.

Here is a brief summary of our tentative conclusions. Please correct me
if anything is misrepresented (details in references):

* Zswap tiering [2]:
  Zswap can itself be a tier (typically the fastest one). But, until vswap lands, 
  zswap cannot be the only allowed tier, 
  since it still needs a physical device for allocation;
  that restriction can be lifted once vswap is supported.
* Vswap tiering [3]:
  Vswap should be handled transparently to the user. Vswap itself will
  not be tiered. But, someday supported if there is strong and real usecase.
* Relationship with zswap.writeback [4]:
  If zswap tiering is introduced, it could replace the zswap-only tier.
  However, since zswap cannot be tiered independently without vswap, it is still
  needed for non-vswap cases.
* Tier demotion [5]:
  A separate interface like memory.swap.tiers.demotion might be needed.
  For now, we only support 0/max to enable/disable tiers. A future "auto"
  mode could scale a per-tier limit from swapfile size and memory.swap.max,
  similar to the direction memory tiering is heading in; the exact
  default-scaling behaviour is still under discussion.

I plan to apply the swap tier infrastructure and the first use case
(cgroup-based swap control) first, and continue following up on the
discussions above.

Overview
========

Swap Tiers group swap devices into performance classes (e.g. NVMe,
HDD, Network) and allow per-memcg selection of which tiers to use.
This mechanism was suggested by Chris Li.

Design Rationale
================

Swap tier selection is attached to memcg. A child cgroup may select a
subset of the parent's allowed tiers.

This
- Preserves cgroup inheritance semantics (boundary at parent,
  refinement at child).
- Reuses memcg, which already groups processes and enforces
  hierarchical memory limits.
- Aligns with existing memcg swap controls (e.g. swap.max, zswap.writeback)
- Avoids introducing a parallel swap control hierarchy.

Placing tier control outside memcg (e.g., via BPF, syscalls, or
madvise) would allow swap preference to diverge from the memcg
hierarchy. Integrating it into memcg keeps the swap policy
consistent with existing memory ownership semantics. There are
also real use cases built around memcg.

In the future, this can be extended to other interfaces to cover
additional use cases.

I believe a memcg-based swap control is a good starting point
before such extensions.

Use Cases
=========

#1: Latency separation (our primary deployment scenario)
  [ / ]
     |
     +-- latency-sensitive workload  (fast tier)
     +-- background workload         (slow tier)

The parent defines the memory boundary.
Each workload selects a swap tier via memory.swap.tiers.max according to
latency requirements.

This prevents latency-sensitive workloads from being swapped to
slow devices used by background workloads.

#2: Per-VM swap selection (Chris Li's deployment scenario)
  [ / ]
     |
     +-- [ Job on VM ]              (tiers: zswap, SSD)
            |
            +-- [ VMM guest memory ]  (tiers: SSD)

The parent (job) has access to both zswap and SSD tiers.
The child (VMM guest memory) selects SSD as its swap tier via
memory.swap.tiers.max. In this deployment, swap device selection
happens at the child level from the parent's available set.

#3: Tier isolation for reduced contention (hypothetical)
  [ / ]                    (tiers: A, B)
     |
     +-- workload X        (tiers: A)
     +-- workload Y        (tiers: B)

Each child uses a different tier. Since swap paths are separated
per tier, synchronization overhead between the two workloads is
reduced.

Future extension (Follow up)
============================

#1: Intra-tier distribution policy:
  Currently, swap devices with the same priority are allocated in a
  round-robin fashion. Per-tier policy files under
  /sys/kernel/mm/swap/tiers/ can control how devices within a tier
  are selected (e.g. round-robin, weighted).

#2: Inter-tier promotion and demotion:
  Promotion and demotion apply between tiers, not within a single
  tier. The current interface defines only tier assignment; it does
  not yet define when or how pages move between tiers. Two triggering
  models are possible:

  (a) User-triggered: userspace explicitly initiates migration between
      tiers (e.g. via a new interface or existing move_pages semantics).
  (b) Kernel-triggered: the kernel moves pages between tiers at
      appropriate points such as reclaim or refault.

#3: Per-VMA, per-process swap and BPF:
  Not just for memcg based swap, possible to extend Per-VMA or per-process
  swap. Or we can use it as BPF program.

#4: Zswap and vswap tiering:
  Tiering applies to the vswap + zswap combination.

#5: Vswap on/off control:
  Currently not supported. If a strong use case arises where vswap needs
  to be controlled by memcg, the tier interface could be used for it.

#6: Per-CPU swap allocation caching:
  Per-si/per-tier per-CPU caching of allocations to reduce contention in
  the tier-filtered allocation path.

Experimentation
===============

Tested on our internal platform using NBD as a separate swap tier.
Our first production's simple usecase.

Without tiers:
- No selective control over flash wear
- Cannot selectively assign NBD to specific applications

Cold launch improvement (preloaded vs. baseline):
- App A: 13.17s -> 4.18s (68%)
- App B: 5.60s -> 1.12s (80%)
- App C: 10.25s -> 2.00s (80%)

Performance impact with no tiers configured:
<1% regression in kernel build and vm-scalability benchmarks

Change log
===========

v10
- selftests: applied the Sashiko review fixes, and dropped redundant comments and dead code.
  (#5, #6 patches)
- Rebased on recent mm-new.
- v9 link: https://lore.kernel.org/linux-mm/20260620181635.299364-1-youngjun.park@lge.com/

v9
- Added selftests (per Nhat's request):
 - selftests/mm: swap tier configuration test for /sys/kernel/mm/swap/tiers.(#5 patch)
 - selftests/cgroup: swap tier routing test for memory.swap.tiers.max. (#6 patch)
- Removed the redundant rcu_read_lock() around the memcg tier-mask tree walk;
  for_each_mem_cgroup_tree() already takes RCU internally and returns each
  memcg with a reference held. (#3 patch)
- Sashiko review: swap_sync_discard() now honors the memcg tier mask, so the
  discard fallback no longer drains clusters on disallowed tiers. Left as-is:
  the cgroup tree walk under spinlock (bounded by cgroup.max.descendants, an
  admin-controlled limit, and triggered only by infrequent tier writes) and
  the pre-existing swap_avail_lock drop in swap_alloc_slow(). (#4 patch)
- Dropped patch #4's Reviewed-by tags (Nhat, Kairui, Baoquan): the
  swap_sync_discard() change above modifies that patch (the tier mask is now
  passed as a parameter into the alloc and discard paths), so the earlier tags
  no longer apply. Re-review would be welcome.
- v8 link: https://lore.kernel.org/linux-mm/20260617053447.2831896-1-youngjun.park@lge.com/

v8
- Changed the memcg interface to memory.swap.tiers.max.
  Values are '0' (disable) and 'max' (enable). Default is 'max'.
- Addressed Sashiko's review: Update the mask value atomically at once and
  read the mask value while grabbing lock.
- Collected review tags from Kairui and Nhat.
- Rebase on recent mm-new
- v7 link: https://lore.kernel.org/linux-mm/20260527062247.3440692-1-youngjun.park@lge.com/

v7
- Collect Baoquan's review tag
- Baoquan's feedback on fixing improper comment
- Minor code adjustments per Baoquan's feedback.
- Rebase on recent mm-new
- v6 link: https://lore.kernel.org/linux-mm/20260421055323.940344-1-youngjun.park@lge.com/

v6
- Sashiko AI review fixes
 - Fix batch parsing error path to restore snapshot before exit
 - Reject overlong tier names to prevent truncated duplicates
 - Avoid restoring raw list_head via memcpy (stale pointer risk)
 - Ensure early parse errors do not skip DEF_SWAP_PRIO validation
 - Use (1U << TIER_DEFAULT_IDX) to avoid signed shift UB
 - Defer tier mask inheritance to css_online() to close race window
 - Add READ_ONCE()/WRITE_ONCE() for tier mask accesses
- Other fixes
 - Fix build error reintroduced due to missing v5 change
 - Fix WARNING in folio_tier_effective_mask by adding rcu_read_lock()
 - default number of swap tier max (change to 32->31, for reserving last bit)
 - commit message refinement.
 - rebased on recently mm-new
- v5 link: https://lore.kernel.org/linux-mm/20260325175453.2523280-1-youngjun.park@lge.com/

v5
- Fixed build errors reported in v4
- rebased on up to date mm-new
- Minor cleanups
- Design docs with validation (by Shakeel Butt discussion)
- v4 link : https://lore.kernel.org/linux-mm/20260217000950.4015880-1-youngjun.park@lge.com/

v4
- Simplified control flow and indentation
- Added CONFIG option for MAX_SWAPTIER (default: 4)
- Added memory.swap.tiers.effective interface
- Reworked save/restore logic into snapshot/rollback model
- Removed tier priority modification support (deferred)
- Improved validation and fixed edge cases
- Rebased onto latest mm-new
- RFC v3 link: https://lore.kernel.org/linux-mm/20260131125454.3187546-1-youngjun.park@lge.com/

RFC v1 ~ v3
- Change the direction after discussion with Chris-Li
- apply some LPC feedback.
- RFC v2 - https://lore.kernel.org/linux-mm/20260126065242.1221862-1-youngjun.park@lge.com/
- RFC v1 - https://lore.kernel.org/linux-mm/20251109124947.1101520-1-youngjun.park@lge.com/

Earlier Approach (per cgroup swap priority)
- v1: https://lore.kernel.org/linux-mm/20250716202006.3640584-1-youngjun.park@lge.com/
- RFC: https://lore.kernel.org/linux-mm/aEvLjEInMQC7hEyh@yjaykim-PowerEdge-T330/T/#mbbb6a5e9e30843097e1f5f65fb98f31d582b973d

Reference
=========

[1] https://lore.kernel.org/linux-doc/aiw2p5ANjsQUCIHA@linux.dev/
[2] https://lore.kernel.org/linux-mm/CAKEwX=Nz9SWcEVQGQjHN8P8OANJY4BG0w+iQOzoNOWuteoVjAg@mail.gmail.com/
[3] https://lore.kernel.org/cgroups/CAKEwX=O23a4iWBZoewKVb8QqODte6r3Xijckw3_oCJNoiO9M5A@mail.gmail.com/
[4] https://lore.kernel.org/linux-mm/CAO9r8zOg0OP1Ak1v7CRzSfQq0D8b4Dw+_T0Jui6YTM_KwQQNOA@mail.gmail.com/
[5] https://lore.kernel.org/linux-mm/CAO9r8zNi4-QC4sUi=xXWHt9WMeG39mbyoSf8kON9vLOZ=cbCmw@mail.gmail.com/

Youngjun Park (6):
  mm: swap: introduce swap tier infrastructure
  mm: swap: associate swap devices with tiers
  mm: memcontrol: add interface for swap tier selection
  mm: swap: filter swap allocation by memcg tier mask
  selftests/mm: add a swap tier configuration test
  selftests/cgroup: add a swap tier routing test

 Documentation/admin-guide/cgroup-v2.rst       |  20 +
 Documentation/mm/index.rst                    |   1 +
 Documentation/mm/swap-tier.rst                | 159 ++++++
 MAINTAINERS                                   |   3 +
 include/linux/memcontrol.h                    |   5 +
 include/linux/swap.h                          |   1 +
 mm/Kconfig                                    |  12 +
 mm/Makefile                                   |   2 +-
 mm/memcontrol.c                               |  67 +++
 mm/swap.h                                     |   4 +
 mm/swap_state.c                               |  75 +++
 mm/swap_tier.c                                | 477 ++++++++++++++++
 mm/swap_tier.h                                |  76 +++
 mm/swapfile.c                                 |  34 +-
 tools/testing/selftests/cgroup/.gitignore     |   1 +
 tools/testing/selftests/cgroup/Makefile       |   2 +
 tools/testing/selftests/cgroup/config         |   2 +
 .../selftests/cgroup/test_swap_tiers.c        | 509 ++++++++++++++++++
 tools/testing/selftests/mm/.gitignore         |   1 +
 tools/testing/selftests/mm/Makefile           |   1 +
 tools/testing/selftests/mm/config             |   2 +
 tools/testing/selftests/mm/run_vmtests.sh     |   5 +
 tools/testing/selftests/mm/swap_tier.c        | 337 ++++++++++++
 23 files changed, 1785 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/mm/swap-tier.rst
 create mode 100644 mm/swap_tier.c
 create mode 100644 mm/swap_tier.h
 create mode 100644 tools/testing/selftests/cgroup/test_swap_tiers.c
 create mode 100644 tools/testing/selftests/mm/swap_tier.c

base-commit: 61cccb8363fcc282d4ae0555b8739dd227f5ad0b
-- 
2.34.1

On Sun, Jul 12, 2026 at 7:57 PM Youngjun Park <youngjun.park@lge.com> wrote:
>
> This is the v10 series of the swap tier patchset.
>
> v10 folds in the Sashiko review fixes for the selftests added in v9 and
> rebases onto the current mm-new. There are no functional changes to the
> core swap or memcg code since v9; see the changelog for details.
>
> For context, the bulk of the series is unchanged since v8, with great thanks
> to Shakeel Butt and Yosry for the reviews and discussions [1] that shaped it.
> The main change in v8 was the interface change to use memory.swap.tiers.max
> with '0' (disable) and 'max' (enable) values. This mechanism was suggested
> by Shakeel and Yosry.
>
> This change allows for future extensions to control swap between tiers and
> aligns better with existing memcg interfaces. It is confined to patch #3's
> user-facing interface; internally, patch #3 still uses the existing mask
> processing method, which is implementation-efficient.
>
> We also discussed tier extensions. Thanks to Yosry, Nhat and Shakeel for their
> valuable feedback.
>
> Here is a brief summary of our tentative conclusions. Please correct me
> if anything is misrepresented (details in references):
>
> * Zswap tiering [2]:
>   Zswap can itself be a tier (typically the fastest one). But, until vswap lands,
>   zswap cannot be the only allowed tier,
>   since it still needs a physical device for allocation;
>   that restriction can be lifted once vswap is supported.

Does this series support zswap being a tier? I cannot find any mention
of zswap in the patches.

On Mon, Jul 13, 2026 at 8:50 AM Yosry Ahmed <yosry@kernel.org> wrote:
>
> On Sun, Jul 12, 2026 at 7:57 PM Youngjun Park <youngjun.park@lge.com> wrote:
> >
> > This is the v10 series of the swap tier patchset.
> >
> > v10 folds in the Sashiko review fixes for the selftests added in v9 and
> > rebases onto the current mm-new. There are no functional changes to the
> > core swap or memcg code since v9; see the changelog for details.
> >
> > For context, the bulk of the series is unchanged since v8, with great thanks
> > to Shakeel Butt and Yosry for the reviews and discussions [1] that shaped it.
> > The main change in v8 was the interface change to use memory.swap.tiers.max
> > with '0' (disable) and 'max' (enable) values. This mechanism was suggested
> > by Shakeel and Yosry.
> >
> > This change allows for future extensions to control swap between tiers and
> > aligns better with existing memcg interfaces. It is confined to patch #3's
> > user-facing interface; internally, patch #3 still uses the existing mask
> > processing method, which is implementation-efficient.
> >
> > We also discussed tier extensions. Thanks to Yosry, Nhat and Shakeel for their
> > valuable feedback.
> >
> > Here is a brief summary of our tentative conclusions. Please correct me
> > if anything is misrepresented (details in references):
> >
> > * Zswap tiering [2]:
> >   Zswap can itself be a tier (typically the fastest one). But, until vswap lands,
> >   zswap cannot be the only allowed tier,
> >   since it still needs a physical device for allocation;
> >   that restriction can be lifted once vswap is supported.
>
> Does this series support zswap being a tier? I cannot find any mention
> of zswap in the patches.

In case I wasn't clear. As it is, zswap is not part of the tier and will not be.

Chris

On Mon, Jul 13, 2026 at 08:50:36AM -0700, Yosry Ahmed wrote:
> On Sun, Jul 12, 2026 at 7:57 PM Youngjun Park <youngjun.park@lge.com> wrote:
> >
> > This is the v10 series of the swap tier patchset.
> >
> > v10 folds in the Sashiko review fixes for the selftests added in v9 and
> > rebases onto the current mm-new. There are no functional changes to the
> > core swap or memcg code since v9; see the changelog for details.
> >
> > For context, the bulk of the series is unchanged since v8, with great thanks
> > to Shakeel Butt and Yosry for the reviews and discussions [1] that shaped it.
> > The main change in v8 was the interface change to use memory.swap.tiers.max
> > with '0' (disable) and 'max' (enable) values. This mechanism was suggested
> > by Shakeel and Yosry.
> >
> > This change allows for future extensions to control swap between tiers and
> > aligns better with existing memcg interfaces. It is confined to patch #3's
> > user-facing interface; internally, patch #3 still uses the existing mask
> > processing method, which is implementation-efficient.
> >
> > We also discussed tier extensions. Thanks to Yosry, Nhat and Shakeel for their
> > valuable feedback.
> >
> > Here is a brief summary of our tentative conclusions. Please correct me
> > if anything is misrepresented (details in references):
> >
> > * Zswap tiering [2]:
> >   Zswap can itself be a tier (typically the fastest one). But, until vswap lands,
> >   zswap cannot be the only allowed tier,
> >   since it still needs a physical device for allocation;
> >   that restriction can be lifted once vswap is supported.
> 
> Does this series support zswap being a tier? I cannot find any mention
> of zswap in the patches.

Hello Yosry!

This series does not cover zswap as a tier yet.

My plan is to land the swap tier infrastructure together with the
first use case (cgroup-based swap control) first, and then follow
up with zswap tier support in a subsequent series, continuing the
discussions we've had above. 
(I mentioned on cover letter, right above the overview section)

Does that approach sound reasonable to you?

On Mon, Jul 13, 2026 at 8:57 AM Youngjun Park <youngjun.park@lge.com> wrote:
>
> On Mon, Jul 13, 2026 at 08:50:36AM -0700, Yosry Ahmed wrote:
> > On Sun, Jul 12, 2026 at 7:57 PM Youngjun Park <youngjun.park@lge.com> wrote:
> > >
> > > This is the v10 series of the swap tier patchset.
> > >
> > > v10 folds in the Sashiko review fixes for the selftests added in v9 and
> > > rebases onto the current mm-new. There are no functional changes to the
> > > core swap or memcg code since v9; see the changelog for details.
> > >
> > > For context, the bulk of the series is unchanged since v8, with great thanks
> > > to Shakeel Butt and Yosry for the reviews and discussions [1] that shaped it.
> > > The main change in v8 was the interface change to use memory.swap.tiers.max
> > > with '0' (disable) and 'max' (enable) values. This mechanism was suggested
> > > by Shakeel and Yosry.
> > >
> > > This change allows for future extensions to control swap between tiers and
> > > aligns better with existing memcg interfaces. It is confined to patch #3's
> > > user-facing interface; internally, patch #3 still uses the existing mask
> > > processing method, which is implementation-efficient.
> > >
> > > We also discussed tier extensions. Thanks to Yosry, Nhat and Shakeel for their
> > > valuable feedback.
> > >
> > > Here is a brief summary of our tentative conclusions. Please correct me
> > > if anything is misrepresented (details in references):
> > >
> > > * Zswap tiering [2]:
> > >   Zswap can itself be a tier (typically the fastest one). But, until vswap lands,
> > >   zswap cannot be the only allowed tier,
> > >   since it still needs a physical device for allocation;
> > >   that restriction can be lifted once vswap is supported.
> >
> > Does this series support zswap being a tier? I cannot find any mention
> > of zswap in the patches.
>
> Hello Yosry!
>
> This series does not cover zswap as a tier yet.
>
> My plan is to land the swap tier infrastructure together with the
> first use case (cgroup-based swap control) first, and then follow
> up with zswap tier support in a subsequent series, continuing the
> discussions we've had above.
> (I mentioned on cover letter, right above the overview section)
>
> Does that approach sound reasonable to you?

How does swap tiering work with zswap in the current series? I assume
zswap is just enabled for all devices in all tiers? I wonder if
introducing zswap as a tier after the fact changes user-visible
behavior. I guess if zswap will be introduced with a default "max"
value it will more-or-less be the same behavior, but I would check all
user-visible behaviors related to zswap (e.g. interaction with other
zswap interfaces) to make sure nothing breaks or changes in a
meaningful way when zswap is introduced as a tier later.

On Mon, Jul 13, 2026 at 9:01 AM Yosry Ahmed <yosry@kernel.org> wrote:
> > My plan is to land the swap tier infrastructure together with the
> > first use case (cgroup-based swap control) first, and then follow
> > up with zswap tier support in a subsequent series, continuing the
> > discussions we've had above.
> > (I mentioned on cover letter, right above the overview section)
> >
> > Does that approach sound reasonable to you?
>
> How does swap tiering work with zswap in the current series? I assume
> zswap is just enabled for all devices in all tiers? I wonder if

Zswap is not part of the tiers exactly because it sits in front of all
swap devices (tiers) and uses a different control to enable or disable
it.
Let's not combine these two; let zswap use its own existing cgroup
control interface.

> introducing zswap as a tier after the fact changes user-visible
> behavior. I guess if zswap will be introduced with a default "max"
> value it will more-or-less be the same behavior, but I would check all
> user-visible behaviors related to zswap (e.g. interaction with other
> zswap interfaces) to make sure nothing breaks or changes in a
> meaningful way when zswap is introduced as a tier later.

Zswap will not be introduced as a tier. The existing user interface
makes zswap not exactly compatible with the tier ordering because it
sits in front of every swapfile. If we change that, we break the user
interface. I suggest we keep zswap working as it is now.

Chris

On Mon, Jul 13, 2026 at 10:03 AM Chris Li <chrisl@kernel.org> wrote:
>
> On Mon, Jul 13, 2026 at 9:01 AM Yosry Ahmed <yosry@kernel.org> wrote:
> > > My plan is to land the swap tier infrastructure together with the
> > > first use case (cgroup-based swap control) first, and then follow
> > > up with zswap tier support in a subsequent series, continuing the
> > > discussions we've had above.
> > > (I mentioned on cover letter, right above the overview section)
> > >
> > > Does that approach sound reasonable to you?
> >
> > How does swap tiering work with zswap in the current series? I assume
> > zswap is just enabled for all devices in all tiers? I wonder if
>
> Zswap is not part of the tiers exactly because it sits in front of all
> swap devices (tiers) and uses a different control to enable or disable
> it.
> Let's not combine these two; let zswap use its own existing cgroup
> control interface.
>
> > introducing zswap as a tier after the fact changes user-visible
> > behavior. I guess if zswap will be introduced with a default "max"
> > value it will more-or-less be the same behavior, but I would check all
> > user-visible behaviors related to zswap (e.g. interaction with other
> > zswap interfaces) to make sure nothing breaks or changes in a
> > meaningful way when zswap is introduced as a tier later.
>
> Zswap will not be introduced as a tier. The existing user interface
> makes zswap not exactly compatible with the tier ordering because it
> sits in front of every swapfile. If we change that, we break the user
> interface. I suggest we keep zswap working as it is now.

The goal from making zswap a swap tier is to have a single framework
to configure swapping for a cgroup, instead of configuring zswap
separately. Yes, zswap currently sits in front of all swap
devices/tiers, but we are heading in the direction of changing that
such that zswap is standalone, at which point it becomes more
obviously a swap tier. If you want us to wait until that happens
before adding zswap as a tier, I don't necessarily object, but I want
to make sure that nothing will break if we add zswap as a tier later.

An advantage of adding zswap as a tier right away is the proactive
writeback use case. It naturally fits in the tiering framework as
proactive demotion between swap tiers, which I expect may be useful in
non-zswap use cases as well. Without zswap as a tier, we'll have to
use a different interface for proactive writeback, and then if/when
zswap becomes a tier, we'll have multiple ways to do proactive
writeback which isn't ideal.

On Mon, Jul 13, 2026 at 10:11 AM Yosry Ahmed <yosry@kernel.org> wrote:
>
> On Mon, Jul 13, 2026 at 10:03 AM Chris Li <chrisl@kernel.org> wrote:
> >
> > On Mon, Jul 13, 2026 at 9:01 AM Yosry Ahmed <yosry@kernel.org> wrote:
> > > > My plan is to land the swap tier infrastructure together with the
> > > > first use case (cgroup-based swap control) first, and then follow
> > > > up with zswap tier support in a subsequent series, continuing the
> > > > discussions we've had above.
> > > > (I mentioned on cover letter, right above the overview section)
> > > >
> > > > Does that approach sound reasonable to you?
> > >
> > > How does swap tiering work with zswap in the current series? I assume
> > > zswap is just enabled for all devices in all tiers? I wonder if
> >
> > Zswap is not part of the tiers exactly because it sits in front of all
> > swap devices (tiers) and uses a different control to enable or disable
> > it.
> > Let's not combine these two; let zswap use its own existing cgroup
> > control interface.
> >
> > > introducing zswap as a tier after the fact changes user-visible
> > > behavior. I guess if zswap will be introduced with a default "max"
> > > value it will more-or-less be the same behavior, but I would check all
> > > user-visible behaviors related to zswap (e.g. interaction with other
> > > zswap interfaces) to make sure nothing breaks or changes in a
> > > meaningful way when zswap is introduced as a tier later.
> >
> > Zswap will not be introduced as a tier. The existing user interface
> > makes zswap not exactly compatible with the tier ordering because it
> > sits in front of every swapfile. If we change that, we break the user
> > interface. I suggest we keep zswap working as it is now.
>
> The goal from making zswap a swap tier is to have a single framework
> to configure swapping for a cgroup, instead of configuring zswap
> separately. Yes, zswap currently sits in front of all swap
> devices/tiers, but we are heading in the direction of changing that
> such that zswap is standalone, at which point it becomes more
> obviously a swap tier. If you want us to wait until that happens
> before adding zswap as a tier, I don't necessarily object, but I want
> to make sure that nothing will break if we add zswap as a tier later.

I'm afraid your zswap user interface will have to break. I don't see a
way around breaking your zswap user interface to fit the swap tiering.
Once we move to the swap tier world, I don't think we should continue
using zswap.writeback to control the tier write back behavior. We will
need to rethink this new world.

> An advantage of adding zswap as a tier right away is the proactive
> writeback use case. It naturally fits in the tiering framework as
> proactive demotion between swap tiers, which I expect may be useful in
> non-zswap use cases as well. Without zswap as a tier, we'll have to
> use a different interface for proactive writeback, and then if/when
> zswap becomes a tier, we'll have multiple ways to do proactive
> writeback which isn't ideal.

I am looking forward to abstracting a more common write back behavior
in the swap tier world. The classic zswap behavior will be preserved.

Chris

> > > Zswap will not be introduced as a tier. The existing user interface
> > > makes zswap not exactly compatible with the tier ordering because it
> > > sits in front of every swapfile. If we change that, we break the user
> > > interface. I suggest we keep zswap working as it is now.
> >
> > The goal from making zswap a swap tier is to have a single framework
> > to configure swapping for a cgroup, instead of configuring zswap
> > separately. Yes, zswap currently sits in front of all swap
> > devices/tiers, but we are heading in the direction of changing that
> > such that zswap is standalone, at which point it becomes more
> > obviously a swap tier. If you want us to wait until that happens
> > before adding zswap as a tier, I don't necessarily object, but I want
> > to make sure that nothing will break if we add zswap as a tier later.
>
> I'm afraid your zswap user interface will have to break. I don't see a
> way around breaking your zswap user interface to fit the swap tiering.
> Once we move to the swap tier world, I don't think we should continue
> using zswap.writeback to control the tier write back behavior. We will
> need to rethink this new world.

I wasn't talking about the existing zswap interfaces. I want to make
sure that if we introduce tiering initially without zswap as a tier,
then add zswap as a tier, the semantics of tiering and user-visible
zswap behavior doesn't break.

That being said, the existing zswap interfaces don't have to break
with tiering, why do they? We may end up with redundant interfaces,
which is unfortunate, and we can work to deprecate some of them over
time. But I don't see why we have to break them?

>
> > An advantage of adding zswap as a tier right away is the proactive
> > writeback use case. It naturally fits in the tiering framework as
> > proactive demotion between swap tiers, which I expect may be useful in
> > non-zswap use cases as well. Without zswap as a tier, we'll have to
> > use a different interface for proactive writeback, and then if/when
> > zswap becomes a tier, we'll have multiple ways to do proactive
> > writeback which isn't ideal.
>
> I am looking forward to abstracting a more common write back behavior
> in the swap tier world. The classic zswap behavior will be preserved.

Right, but this requires zswap being a tier, which you seem to be opposed to :)

On Mon, Jul 13, 2026 at 11:38 AM Yosry Ahmed <yosry@kernel.org> wrote:
>
> > > > Zswap will not be introduced as a tier. The existing user interface
> > > > makes zswap not exactly compatible with the tier ordering because it
> > > > sits in front of every swapfile. If we change that, we break the user
> > > > interface. I suggest we keep zswap working as it is now.
> > >
> > > The goal from making zswap a swap tier is to have a single framework
> > > to configure swapping for a cgroup, instead of configuring zswap
> > > separately. Yes, zswap currently sits in front of all swap
> > > devices/tiers, but we are heading in the direction of changing that
> > > such that zswap is standalone, at which point it becomes more
> > > obviously a swap tier. If you want us to wait until that happens
> > > before adding zswap as a tier, I don't necessarily object, but I want
> > > to make sure that nothing will break if we add zswap as a tier later.
> >
> > I'm afraid your zswap user interface will have to break. I don't see a
> > way around breaking your zswap user interface to fit the swap tiering.
> > Once we move to the swap tier world, I don't think we should continue
> > using zswap.writeback to control the tier write back behavior. We will
> > need to rethink this new world.
>
> I wasn't talking about the existing zswap interfaces. I want to make
> sure that if we introduce tiering initially without zswap as a tier,
> then add zswap as a tier, the semantics of tiering and user-visible
> zswap behavior doesn't break.

No, the user visible part of zswap must break because zswap currently
sits in front of every swapfile.
I don't see any other way around it.

If you do know how zswap can interact with swap.tiers without breaking
the user interface, make a formal proposal and lay out all the
details. I did that exercise myself and I my conclusion is that it is
better to accept zswap is the classic behavior without burdening the
unified swap tier too much.

> That being said, the existing zswap interfaces don't have to break
> with tiering, why do they? We may end up with redundant interfaces,

Because zswap does not have its own swap device, it borrows the swap
slot from the underlying swap device. That behavior is unique to zswap
and none of the other swap tiers have that.

> which is unfortunate, and we can work to deprecate some of them over
> time. But I don't see why we have to break them?

I don't want to special case the zswap for from the swap tiers.

> > > An advantage of adding zswap as a tier right away is the proactive
> > > writeback use case. It naturally fits in the tiering framework as
> > > proactive demotion between swap tiers, which I expect may be useful in
> > > non-zswap use cases as well. Without zswap as a tier, we'll have to
> > > use a different interface for proactive writeback, and then if/when
> > > zswap becomes a tier, we'll have multiple ways to do proactive
> > > writeback which isn't ideal.
> >
> > I am looking forward to abstracting a more common write back behavior
> > in the swap tier world. The classic zswap behavior will be preserved.
>
> Right, but this requires zswap being a tier, which you seem to be opposed to :)

It does not need to as far as I can tell. People who want classic
zswap can use zswap as it is. I am thinking the swap ops provide some
interface for classic zswap to use, but zswap itself is not a tier
because it does not own swap devices.

Chris

On Mon, Jul 13, 2026 at 12:39 PM Chris Li <chrisl@kernel.org> wrote:
>
> On Mon, Jul 13, 2026 at 11:38 AM Yosry Ahmed <yosry@kernel.org> wrote:
> >
> > > > > Zswap will not be introduced as a tier. The existing user interface
> > > > > makes zswap not exactly compatible with the tier ordering because it
> > > > > sits in front of every swapfile. If we change that, we break the user
> > > > > interface. I suggest we keep zswap working as it is now.
> > > >
> > > > The goal from making zswap a swap tier is to have a single framework
> > > > to configure swapping for a cgroup, instead of configuring zswap
> > > > separately. Yes, zswap currently sits in front of all swap
> > > > devices/tiers, but we are heading in the direction of changing that
> > > > such that zswap is standalone, at which point it becomes more
> > > > obviously a swap tier. If you want us to wait until that happens
> > > > before adding zswap as a tier, I don't necessarily object, but I want
> > > > to make sure that nothing will break if we add zswap as a tier later.
> > >
> > > I'm afraid your zswap user interface will have to break. I don't see a
> > > way around breaking your zswap user interface to fit the swap tiering.
> > > Once we move to the swap tier world, I don't think we should continue
> > > using zswap.writeback to control the tier write back behavior. We will
> > > need to rethink this new world.
> >
> > I wasn't talking about the existing zswap interfaces. I want to make
> > sure that if we introduce tiering initially without zswap as a tier,
> > then add zswap as a tier, the semantics of tiering and user-visible
> > zswap behavior doesn't break.
>
> No, the user visible part of zswap must break because zswap currently
> sits in front of every swapfile.
> I don't see any other way around it.

If zswap becomes usable independent from a swapfile, it's mostly
transparent to current users.

> If you do know how zswap can interact with swap.tiers without breaking
> the user interface, make a formal proposal and lay out all the
> details. I did that exercise myself and I my conclusion is that it is
> better to accept zswap is the classic behavior without burdening the
> unified swap tier too much.

Today pages go to zswap, and when the limit is hit they get written
back to a swap device. If zswap is a separate tier, pages will still
go to zswap and then when the limit is hit they get written back to a
swap device. In both cases, zswap writeback can be disabled.

Can you share the findings from your exercise, and why zswap being a
tier is a burden? Any specific examples?

>
> > That being said, the existing zswap interfaces don't have to break
> > with tiering, why do they? We may end up with redundant interfaces,
>
> Because zswap does not have its own swap device, it borrows the swap
> slot from the underlying swap device. That behavior is unique to zswap
> and none of the other swap tiers have that.

Yes, but we are heading in the direction of removing that restriction.
But I also don't see the connection between that and the current
interfaces breaking. Do you have any concrete examples?

>
> > which is unfortunate, and we can work to deprecate some of them over
> > time. But I don't see why we have to break them?
>
> I don't want to special case the zswap for from the swap tiers.

Neither do I, but I fail to see where the special casing is, beyond
the fact that zswap is not a swapfile but an in-memory swap.

> > > > An advantage of adding zswap as a tier right away is the proactive
> > > > writeback use case. It naturally fits in the tiering framework as
> > > > proactive demotion between swap tiers, which I expect may be useful in
> > > > non-zswap use cases as well. Without zswap as a tier, we'll have to
> > > > use a different interface for proactive writeback, and then if/when
> > > > zswap becomes a tier, we'll have multiple ways to do proactive
> > > > writeback which isn't ideal.
> > >
> > > I am looking forward to abstracting a more common write back behavior
> > > in the swap tier world. The classic zswap behavior will be preserved.
> >
> > Right, but this requires zswap being a tier, which you seem to be opposed to :)
>
> It does not need to as far as I can tell. People who want classic
> zswap can use zswap as it is. I am thinking the swap ops provide some
> interface for classic zswap to use, but zswap itself is not a tier
> because it does not own swap devices.

A swap tier represents a class of swap devices or swap files with
specific characteristics. Zswap satisfies that, although it's not
really a swap device/file.

On Mon, Jul 13, 2026 at 12:57 PM Yosry Ahmed <yosry@kernel.org> wrote:
>
> On Mon, Jul 13, 2026 at 12:39 PM Chris Li <chrisl@kernel.org> wrote:
> >
> > On Mon, Jul 13, 2026 at 11:38 AM Yosry Ahmed <yosry@kernel.org> wrote:
> > >
> > > > > > Zswap will not be introduced as a tier. The existing user interface
> > > > > > makes zswap not exactly compatible with the tier ordering because it
> > > > > > sits in front of every swapfile. If we change that, we break the user
> > > > > > interface. I suggest we keep zswap working as it is now.
> > > > >
> > > > > The goal from making zswap a swap tier is to have a single framework
> > > > > to configure swapping for a cgroup, instead of configuring zswap
> > > > > separately. Yes, zswap currently sits in front of all swap
> > > > > devices/tiers, but we are heading in the direction of changing that
> > > > > such that zswap is standalone, at which point it becomes more
> > > > > obviously a swap tier. If you want us to wait until that happens
> > > > > before adding zswap as a tier, I don't necessarily object, but I want
> > > > > to make sure that nothing will break if we add zswap as a tier later.
> > > >
> > > > I'm afraid your zswap user interface will have to break. I don't see a
> > > > way around breaking your zswap user interface to fit the swap tiering.
> > > > Once we move to the swap tier world, I don't think we should continue
> > > > using zswap.writeback to control the tier write back behavior. We will
> > > > need to rethink this new world.
> > >
> > > I wasn't talking about the existing zswap interfaces. I want to make
> > > sure that if we introduce tiering initially without zswap as a tier,
> > > then add zswap as a tier, the semantics of tiering and user-visible
> > > zswap behavior doesn't break.
> >
> > No, the user visible part of zswap must break because zswap currently
> > sits in front of every swapfile.
> > I don't see any other way around it.
>
> If zswap becomes usable independent from a swapfile, it's mostly
> transparent to current users.
>
> > If you do know how zswap can interact with swap.tiers without breaking
> > the user interface, make a formal proposal and lay out all the
> > details. I did that exercise myself and I my conclusion is that it is
> > better to accept zswap is the classic behavior without burdening the
> > unified swap tier too much.
>
> Today pages go to zswap, and when the limit is hit they get written
> back to a swap device. If zswap is a separate tier, pages will still
> go to zswap and then when the limit is hit they get written back to a
> swap device. In both cases, zswap writeback can be disabled.
>
> Can you share the findings from your exercise, and why zswap being a
> tier is a burden? Any specific examples?

It is all good when you have only zswap and just one other tier of swap device.
As soon as you add one more, e.g. zswap -> SSD -> HDD will make things
complicate when zswap using the HDD slot write back direclty to HDD.
Anyway, I find that this kind of highlevel hand waving discussion of
pros and cons usually doesn't produce the useful outcome. If you have
a detailed solution for how zswap works with multiple layers of swap
tiers, Laying out all the details and even better, providing some
incremental patches, is the better way to proceed.

> > > That being said, the existing zswap interfaces don't have to break
> > > with tiering, why do they? We may end up with redundant interfaces,
> >
> > Because zswap does not have its own swap device, it borrows the swap
> > slot from the underlying swap device. That behavior is unique to zswap
> > and none of the other swap tiers have that.
>
> Yes, but we are heading in the direction of removing that restriction.
> But I also don't see the connection between that and the current
> interfaces breaking. Do you have any concrete examples?

See above. This topic has already seen a lot of heated discussion.
Show me an incrementally mergeable patch; that would be a better way
to move forward.

Chris

On Mon, Jul 13, 2026 at 09:01:20AM -0700, Yosry Ahmed wrote:
> On Mon, Jul 13, 2026 at 8:57 AM Youngjun Park <youngjun.park@lge.com> wrote:
> >
> > On Mon, Jul 13, 2026 at 08:50:36AM -0700, Yosry Ahmed wrote:
> > > On Sun, Jul 12, 2026 at 7:57 PM Youngjun Park <youngjun.park@lge.com> wrote:
> > > >
> > > > This is the v10 series of the swap tier patchset.
> > > >
> > > > v10 folds in the Sashiko review fixes for the selftests added in v9 and
> > > > rebases onto the current mm-new. There are no functional changes to the
> > > > core swap or memcg code since v9; see the changelog for details.
> > > >
> > > > For context, the bulk of the series is unchanged since v8, with great thanks
> > > > to Shakeel Butt and Yosry for the reviews and discussions [1] that shaped it.
> > > > The main change in v8 was the interface change to use memory.swap.tiers.max
> > > > with '0' (disable) and 'max' (enable) values. This mechanism was suggested
> > > > by Shakeel and Yosry.
> > > >
> > > > This change allows for future extensions to control swap between tiers and
> > > > aligns better with existing memcg interfaces. It is confined to patch #3's
> > > > user-facing interface; internally, patch #3 still uses the existing mask
> > > > processing method, which is implementation-efficient.
> > > >
> > > > We also discussed tier extensions. Thanks to Yosry, Nhat and Shakeel for their
> > > > valuable feedback.
> > > >
> > > > Here is a brief summary of our tentative conclusions. Please correct me
> > > > if anything is misrepresented (details in references):
> > > >
> > > > * Zswap tiering [2]:
> > > >   Zswap can itself be a tier (typically the fastest one). But, until vswap lands,
> > > >   zswap cannot be the only allowed tier,
> > > >   since it still needs a physical device for allocation;
> > > >   that restriction can be lifted once vswap is supported.
> > >
> > > Does this series support zswap being a tier? I cannot find any mention
> > > of zswap in the patches.
> >
> > Hello Yosry!
> >
> > This series does not cover zswap as a tier yet.
> >
> > My plan is to land the swap tier infrastructure together with the
> > first use case (cgroup-based swap control) first, and then follow
> > up with zswap tier support in a subsequent series, continuing the
> > discussions we've had above.
> > (I mentioned on cover letter, right above the overview section)
> >
> > Does that approach sound reasonable to you?
> 
> How does swap tiering work with zswap in the current series? I assume
> zswap is just enabled for all devices in all tiers?

Yes, that's correct.

> I wonder if introducing zswap as a tier after the fact changes user-visible
> behavior. I guess if zswap will be introduced with a default "max"
> value it will more-or-less be the same behavior,

Right, that's the plan.

> but I would check all
> user-visible behaviors related to zswap (e.g. interaction with other
> zswap interfaces) to make sure nothing breaks or changes in a
> meaningful way when zswap is introduced as a tier later.

Fair point. Let me review this more and get back to you!

Thanks,
Youngjun

Hi Youngjun,

Thanks for keep pushing this effort.

On Tue, Jul 14, 2026 at 01:22:42AM +0900, Youngjun Park wrote:
> On Mon, Jul 13, 2026 at 09:01:20AM -0700, Yosry Ahmed wrote:
> > On Mon, Jul 13, 2026 at 8:57 AM Youngjun Park <youngjun.park@lge.com> wrote:
> > >
> > > On Mon, Jul 13, 2026 at 08:50:36AM -0700, Yosry Ahmed wrote:
> > > > On Sun, Jul 12, 2026 at 7:57 PM Youngjun Park <youngjun.park@lge.com> wrote:
> > > > >
> > > > > This is the v10 series of the swap tier patchset.
> > > > >
> > > > > v10 folds in the Sashiko review fixes for the selftests added in v9 and
> > > > > rebases onto the current mm-new. There are no functional changes to the
> > > > > core swap or memcg code since v9; see the changelog for details.
> > > > >
> > > > > For context, the bulk of the series is unchanged since v8, with great thanks
> > > > > to Shakeel Butt and Yosry for the reviews and discussions [1] that shaped it.
> > > > > The main change in v8 was the interface change to use memory.swap.tiers.max
> > > > > with '0' (disable) and 'max' (enable) values. This mechanism was suggested
> > > > > by Shakeel and Yosry.
> > > > >
> > > > > This change allows for future extensions to control swap between tiers and
> > > > > aligns better with existing memcg interfaces. It is confined to patch #3's
> > > > > user-facing interface; internally, patch #3 still uses the existing mask
> > > > > processing method, which is implementation-efficient.
> > > > >
> > > > > We also discussed tier extensions. Thanks to Yosry, Nhat and Shakeel for their
> > > > > valuable feedback.
> > > > >
> > > > > Here is a brief summary of our tentative conclusions. Please correct me
> > > > > if anything is misrepresented (details in references):
> > > > >
> > > > > * Zswap tiering [2]:
> > > > >   Zswap can itself be a tier (typically the fastest one). But, until vswap lands,
> > > > >   zswap cannot be the only allowed tier,
> > > > >   since it still needs a physical device for allocation;
> > > > >   that restriction can be lifted once vswap is supported.
> > > >
> > > > Does this series support zswap being a tier? I cannot find any mention
> > > > of zswap in the patches.
> > >
> > > Hello Yosry!
> > >
> > > This series does not cover zswap as a tier yet.
> > >
> > > My plan is to land the swap tier infrastructure together with the
> > > first use case (cgroup-based swap control) first, and then follow
> > > up with zswap tier support in a subsequent series, continuing the
> > > discussions we've had above.
> > > (I mentioned on cover letter, right above the overview section)
> > >
> > > Does that approach sound reasonable to you?
> > 
> > How does swap tiering work with zswap in the current series? I assume
> > zswap is just enabled for all devices in all tiers?
> 
> Yes, that's correct.
> 
> > I wonder if introducing zswap as a tier after the fact changes user-visible
> > behavior. I guess if zswap will be introduced with a default "max"
> > value it will more-or-less be the same behavior,
> 
> Right, that's the plan.
> 
> > but I would check all
> > user-visible behaviors related to zswap (e.g. interaction with other
> > zswap interfaces) to make sure nothing breaks or changes in a
> > meaningful way when zswap is introduced as a tier later.
> 
> Fair point. Let me review this more and get back to you!

Please do report back what you find.

Yosry, what is needed to enable zswap as a swap tier? What will be the minimum
requirements for that? If that is not too much, we can make that part of this
series.

Shakeel

On Tue, Jul 14, 2026 at 01:44:28PM -0700, Shakeel Butt wrote:
> Hi Youngjun,
> 
> Thanks for keep pushing this effort.

Hi Shakeel
Huge thanks again for suggestion.

> > Right, that's the plan.
> > 
> > > but I would check all
> > > user-visible behaviors related to zswap (e.g. interaction with other
> > > zswap interfaces) to make sure nothing breaks or changes in a
> > > meaningful way when zswap is introduced as a tier later.

At now, the answer is there are nothing breaks or changes as a first review.
I think it'll be better to introduce zswap tier after this patch.
(Details are going on the below)

> > Fair point. Let me review this more and get back to you!
> 
> Please do report back what you find.
> 
> Yosry, what is needed to enable zswap as a swap tier? What will be the minimum
> requirements for that? If that is not too much, we can make that part of this
> series.
> 
> Shakeel

I tried to verify what changes once the zswap tier is introduced.
Please correct me if I'm wrong!

First observation: before the zswap tier is introduced, some of this
is already possible today:

  - a "zswap-only" tier equivalent on cgroup: memory.zswap.writeback = 0
  - disabling zswap entirely on cgroup: memory.zswap.max = 0
  - disabling swap (and zswap) entirely on cgroup: memory.swap.max = 0

Given that, my take is that introducing the tier concept itself
doesn't change any user-visible zswap behavior, since on/off control
for the zswap tier is basically already possible today through other
knobs. So this isn't really a user-facing problem; it's more
something we need to think through carefully in the patch that
introduces the tier concept itself. That's what the points below are
about.

The cgroup interface knobs and the zswap-global knobs need a
different kind of review, so let's start with the global ones. The
zswap-global knobs (compressor, max_pool_percent,
accept_threshold_percent, shrinker_enabled) look fine with tiers.
They're zswap-internal tuning, orthogonal to the tier concept, so
tiers shouldn't change their behavior. The remaining one, "enabled",
does overlap in spirit with the tier on/off knob: enabled = false is
basically the same as disabling zswap for every cgroup. But like the
other overlaps below, this doesn't look like a real problem.

The part that needs more thought is the overlap between
memory.zswap.max / memory.zswap.writeback, memory.swap.max, and the
new tier on/off knob. Since all of the above is already possible
today, adding a tier on top means we should make sure it doesn't
create confusing overlap.

1) memory.swap.max vs. tier on/off

   memory.swap.max = 0 disables swap (and zswap) entirely, and
   memory.swap.max = max leaves everything enabled, so one knob can
   make the other a no-op. I don't think this is confusing in
   practice; they're just two independent ways to reach the same end
   state.

   Conceptually, the tier knob controls on/off/auto-scale, while
   memory.swap.max controls pure quantity, so they cover different
   concerns and can coexist. Even if the tier knob later takes a
   numeric value, that number would apply per tier, while swap.max is
   a total budget that doesn't care how the tiers split it up, so
   they still shouldn't step on each other.

2) memory.zswap.max vs. zswap tier on/off

   memory.zswap.max = 0 looks semantically equivalent to turning the
   zswap tier off. Could memory.zswap.max simply be folded into
   memory.<zswap_tier_name>.max?

   Yosry pointed out:

   > > memory.zswap.max integrates naturally (it's
   > > memory.<tier_name>.max).
   > Not really. memory.zswap.max is in terms of memory usage
   > (compressed size), not swap usage (uncompressed size).

   I'm not sure where the tier limit would actually apply here: is it
   checked in zswap_store() against the pre-compression size, while
   memory.zswap.max keeps tracking the compressed size? If so, once
   you give the tier limit a number, wouldn't its usage end up
   meaning basically the same thing as memory.zswap.max? For limit =
   0 the two already look identical to me (both just block zswap
   usage). I'd like to understand what benefit a non-zero tier limit
   (uncompressed) gives us over the existing memory.zswap.max
   (compressed), once tiers exist. Let me know if I'm missing
   something here.

   Also note the mixed states this creates:

     - memory.zswap.max has room, but the tier is off, so zswap can't
       be used.
     - memory.zswap.max = 0, but the tier is on, so zswap still can't
       be used.

   Both knobs can independently block zswap usage, which seems worth
   flagging even if it's not harmful by itself.

   On top of that, the tier knob is likely to stay on/off/auto-scale
   without a numeric limit, while memory.zswap.max only handles the
   numeric side, so the two should coexist as is. If the tier ever
   gains its own numeric limit, we'd need to revisit unifying it with
   memory.zswap.max.

3) memory.zswap.writeback vs. a "zswap-only" tier

   memory.zswap.writeback = 0 can act like a zswap-only tier today,
   because zswap still borrows a slot from the real swap device to
   store data; writeback = 0 just skips writing that data out to the
   device . A tier restriction works differently: it applies at
   allocation time, so a zswap-only tier would block allocating any
   slot from another device. Since zswap currently depends on that
   very slot to store anything, this would break zswap instead of
   giving us a working zswap-only mode, so the tier restriction can't
   substitute for memory.zswap.writeback here.

   With vswap, this changes: tier off and writeback = 0 converge to
   the same effect(right now the pure zswap only tier),
   since zswap no longer needs to borrow a slot from
   another device. Even so, memory.zswap.writeback still needs to
   stay, since vswap itself can be disabled at compile time or
   runtime, and we'd still need a way to express zswap-only behavior
   without it. I'd like to unify the two eventually, but for now they
   have to stay separate. I'll keep thinking about it.

How do you think?

thanks
Youngjun

On Tue, Jul 14, 2026 at 10:45 PM Youngjun Park <youngjun.park@lge.com> wrote:
>
> On Tue, Jul 14, 2026 at 01:44:28PM -0700, Shakeel Butt wrote:
> > Hi Youngjun,
> >
> > Thanks for keep pushing this effort.
>
> Hi Shakeel
> Huge thanks again for suggestion.
>
> > > Right, that's the plan.
> > >
> > > > but I would check all
> > > > user-visible behaviors related to zswap (e.g. interaction with other
> > > > zswap interfaces) to make sure nothing breaks or changes in a
> > > > meaningful way when zswap is introduced as a tier later.
>
> At now, the answer is there are nothing breaks or changes as a first review.
> I think it'll be better to introduce zswap tier after this patch.

I am fine with that.

> (Details are going on the below)
>
> > > Fair point. Let me review this more and get back to you!
> >
> > Please do report back what you find.
> >
> > Yosry, what is needed to enable zswap as a swap tier? What will be the minimum
> > requirements for that? If that is not too much, we can make that part of this
> > series.
> >
> > Shakeel
>
> I tried to verify what changes once the zswap tier is introduced.
> Please correct me if I'm wrong!
>
> First observation: before the zswap tier is introduced, some of this
> is already possible today:
>
>   - a "zswap-only" tier equivalent on cgroup: memory.zswap.writeback = 0
>   - disabling zswap entirely on cgroup: memory.zswap.max = 0
>   - disabling swap (and zswap) entirely on cgroup: memory.swap.max = 0
>
> Given that, my take is that introducing the tier concept itself
> doesn't change any user-visible zswap behavior, since on/off control
> for the zswap tier is basically already possible today through other
> knobs. So this isn't really a user-facing problem; it's more
> something we need to think through carefully in the patch that
> introduces the tier concept itself. That's what the points below are
> about.
>
> The cgroup interface knobs and the zswap-global knobs need a
> different kind of review, so let's start with the global ones. The
> zswap-global knobs (compressor, max_pool_percent,
> accept_threshold_percent, shrinker_enabled) look fine with tiers.
> They're zswap-internal tuning, orthogonal to the tier concept, so
> tiers shouldn't change their behavior. The remaining one, "enabled",
> does overlap in spirit with the tier on/off knob: enabled = false is
> basically the same as disabling zswap for every cgroup. But like the
> other overlaps below, this doesn't look like a real problem.
>
> The part that needs more thought is the overlap between
> memory.zswap.max / memory.zswap.writeback, memory.swap.max, and the
> new tier on/off knob. Since all of the above is already possible
> today, adding a tier on top means we should make sure it doesn't
> create confusing overlap.
>
> 1) memory.swap.max vs. tier on/off
>
>    memory.swap.max = 0 disables swap (and zswap) entirely, and
>    memory.swap.max = max leaves everything enabled, so one knob can
>    make the other a no-op. I don't think this is confusing in
>    practice; they're just two independent ways to reach the same end
>    state.
>
>    Conceptually, the tier knob controls on/off/auto-scale, while
>    memory.swap.max controls pure quantity, so they cover different
>    concerns and can coexist. Even if the tier knob later takes a
>    numeric value, that number would apply per tier, while swap.max is
>    a total budget that doesn't care how the tiers split it up, so
>    they still shouldn't step on each other.

Ack.

> 2) memory.zswap.max vs. zswap tier on/off
>
>    memory.zswap.max = 0 looks semantically equivalent to turning the
>    zswap tier off. Could memory.zswap.max simply be folded into
>    memory.<zswap_tier_name>.max?
>
>    Yosry pointed out:
>
>    > > memory.zswap.max integrates naturally (it's
>    > > memory.<tier_name>.max).
>    > Not really. memory.zswap.max is in terms of memory usage
>    > (compressed size), not swap usage (uncompressed size).
>
>    I'm not sure where the tier limit would actually apply here: is it
>    checked in zswap_store() against the pre-compression size, while
>    memory.zswap.max keeps tracking the compressed size? If so, once
>    you give the tier limit a number, wouldn't its usage end up
>    meaning basically the same thing as memory.zswap.max? For limit =
>    0 the two already look identical to me (both just block zswap
>    usage). I'd like to understand what benefit a non-zero tier limit
>    (uncompressed) gives us over the existing memory.zswap.max
>    (compressed), once tiers exist. Let me know if I'm missing
>    something here.
>
>    Also note the mixed states this creates:
>
>      - memory.zswap.max has room, but the tier is off, so zswap can't
>        be used.
>      - memory.zswap.max = 0, but the tier is on, so zswap still can't
>        be used.

I this is more of the zswap interal behavior, I don't have a strong
preference.  I will let the zswap experts comment  on that.
>
>    Both knobs can independently block zswap usage, which seems worth
>    flagging even if it's not harmful by itself.
>
>    On top of that, the tier knob is likely to stay on/off/auto-scale
>    without a numeric limit, while memory.zswap.max only handles the
>    numeric side, so the two should coexist as is. If the tier ever
>    gains its own numeric limit, we'd need to revisit unifying it with
>    memory.zswap.max.

Ack.

>
> 3) memory.zswap.writeback vs. a "zswap-only" tier
>
>    memory.zswap.writeback = 0 can act like a zswap-only tier today,
>    because zswap still borrows a slot from the real swap device to
>    store data; writeback = 0 just skips writing that data out to the
>    device . A tier restriction works differently: it applies at
>    allocation time, so a zswap-only tier would block allocating any
>    slot from another device. Since zswap currently depends on that
>    very slot to store anything, this would break zswap instead of
>    giving us a working zswap-only mode, so the tier restriction can't
>    substitute for memory.zswap.writeback here.

zswap.writeback = 0 will disable the other swap device after that.
That is the incompatible part of the interface with swap tiers. I
think if you want to use swap tiers other than zswap, you will have to
leave the writeback = true.

>    With vswap, this changes: tier off and writeback = 0 converge to
>    the same effect(right now the pure zswap only tier),
>    since zswap no longer needs to borrow a slot from
>    another device. Even so, memory.zswap.writeback still needs to
>    stay, since vswap itself can be disabled at compile time or
>    runtime, and we'd still need a way to express zswap-only behavior
>    without it. I'd like to unify the two eventually, but for now they
>    have to stay separate. I'll keep thinking about it.
>
> How do you think?

I think with vswap/Xswap/ghostswapfile it is a totally different
world. It would better to create conceptually separate entities rather
than cling to the current zswap. They can share code, but the mental
concept is different. The zswap behavior of borrowing a swap slot from
the other swap device will likely need to change there. It is another
can of worms I don't want to open right now. We should defer that to
later.

Chris

On Tue, Jul 14, 2026 at 10:45 PM Youngjun Park <youngjun.park@lge.com> wrote:
>
> On Tue, Jul 14, 2026 at 01:44:28PM -0700, Shakeel Butt wrote:
> > Hi Youngjun,
> >
> > Thanks for keep pushing this effort.
>
> Hi Shakeel
> Huge thanks again for suggestion.
>
> > > Right, that's the plan.
> > >
> > > > but I would check all
> > > > user-visible behaviors related to zswap (e.g. interaction with other
> > > > zswap interfaces) to make sure nothing breaks or changes in a
> > > > meaningful way when zswap is introduced as a tier later.
>
> At now, the answer is there are nothing breaks or changes as a first review.
> I think it'll be better to introduce zswap tier after this patch.
> (Details are going on the below)
>
> > > Fair point. Let me review this more and get back to you!
> >
> > Please do report back what you find.
> >
> > Yosry, what is needed to enable zswap as a swap tier? What will be the minimum
> > requirements for that? If that is not too much, we can make that part of this
> > series.
> >
> > Shakeel
>
> I tried to verify what changes once the zswap tier is introduced.
> Please correct me if I'm wrong!
>
> First observation: before the zswap tier is introduced, some of this
> is already possible today:
>
>   - a "zswap-only" tier equivalent on cgroup: memory.zswap.writeback = 0
>   - disabling zswap entirely on cgroup: memory.zswap.max = 0
>   - disabling swap (and zswap) entirely on cgroup: memory.swap.max = 0
>
> Given that, my take is that introducing the tier concept itself
> doesn't change any user-visible zswap behavior, since on/off control
> for the zswap tier is basically already possible today through other
> knobs. So this isn't really a user-facing problem; it's more
> something we need to think through carefully in the patch that
> introduces the tier concept itself. That's what the points below are
> about.
>
> The cgroup interface knobs and the zswap-global knobs need a
> different kind of review, so let's start with the global ones. The
> zswap-global knobs (compressor, max_pool_percent,
> accept_threshold_percent, shrinker_enabled) look fine with tiers.
> They're zswap-internal tuning, orthogonal to the tier concept, so
> tiers shouldn't change their behavior. The remaining one, "enabled",
> does overlap in spirit with the tier on/off knob: enabled = false is
> basically the same as disabling zswap for every cgroup. But like the
> other overlaps below, this doesn't look like a real problem.

Agreed, I don't think there's a problem there.

>
> The part that needs more thought is the overlap between
> memory.zswap.max / memory.zswap.writeback, memory.swap.max, and the
> new tier on/off knob. Since all of the above is already possible
> today, adding a tier on top means we should make sure it doesn't
> create confusing overlap.
>
> 1) memory.swap.max vs. tier on/off
>
>    memory.swap.max = 0 disables swap (and zswap) entirely, and
>    memory.swap.max = max leaves everything enabled, so one knob can
>    make the other a no-op. I don't think this is confusing in
>    practice; they're just two independent ways to reach the same end
>    state.
>
>    Conceptually, the tier knob controls on/off/auto-scale, while
>    memory.swap.max controls pure quantity, so they cover different
>    concerns and can coexist. Even if the tier knob later takes a
>    numeric value, that number would apply per tier, while swap.max is
>    a total budget that doesn't care how the tiers split it up, so
>    they still shouldn't step on each other.

The memory.swap.max interaction with tier on/off would be the same as
memory.max with memory tiers AFAICT. We just need to make sure we
remain consistent.

> 2) memory.zswap.max vs. zswap tier on/off
>
>    memory.zswap.max = 0 looks semantically equivalent to turning the
>    zswap tier off. Could memory.zswap.max simply be folded into
>    memory.<zswap_tier_name>.max?
>
>    Yosry pointed out:
>
>    > > memory.zswap.max integrates naturally (it's
>    > > memory.<tier_name>.max).
>    > Not really. memory.zswap.max is in terms of memory usage
>    > (compressed size), not swap usage (uncompressed size).
>
>    I'm not sure where the tier limit would actually apply here: is it
>    checked in zswap_store() against the pre-compression size, while
>    memory.zswap.max keeps tracking the compressed size?

As the tier limit can only be 0 or max for now, I don't think this is
a problem. zswap_store() would just check that the tier is not
disabled.

>    If so, once you give the tier limit a number, wouldn't its usage end up
>    meaning basically the same thing as memory.zswap.max?

If we allow values other than 0/max, I think for zswap that would be
the limit on the uncompressed size to remain consistent with other
swap tiers. So it would be different from memory.zswap.max.

> For limit = 0 the two already look identical to me (both just block zswap
>    usage). I'd like to understand what benefit a non-zero tier limit
>    (uncompressed) gives us over the existing memory.zswap.max
>    (compressed), once tiers exist. Let me know if I'm missing
>    something here.

Yeah limit=0 and limit=max would behave similarly for both. If we do
support other limits, the meaning would be different. Since most usage
of zswap.max is either setting it to 0/max, we can check if we can
deprecate that interface once we add zswap as a tier.

>    Also note the mixed states this creates:
>
>      - memory.zswap.max has room, but the tier is off, so zswap can't
>        be used.
>      - memory.zswap.max = 0, but the tier is on, so zswap still can't
>        be used.
>
>    Both knobs can independently block zswap usage, which seems worth
>    flagging even if it's not harmful by itself.
>
>    On top of that, the tier knob is likely to stay on/off/auto-scale
>    without a numeric limit, while memory.zswap.max only handles the
>    numeric side, so the two should coexist as is. If the tier ever
>    gains its own numeric limit, we'd need to revisit unifying it with
>    memory.zswap.max.
>
> 3) memory.zswap.writeback vs. a "zswap-only" tier
>
>    memory.zswap.writeback = 0 can act like a zswap-only tier today,
>    because zswap still borrows a slot from the real swap device to
>    store data; writeback = 0 just skips writing that data out to the
>    device . A tier restriction works differently: it applies at
>    allocation time, so a zswap-only tier would block allocating any
>    slot from another device. Since zswap currently depends on that
>    very slot to store anything, this would break zswap instead of
>    giving us a working zswap-only mode, so the tier restriction can't
>    substitute for memory.zswap.writeback here.

Yes, the semantics of zswap.writeback would be different than using
zswap as the only tier, but we shouldn't allow zswap as the only tier
anyway as I mentioned.

>    With vswap, this changes: tier off and writeback = 0 converge to
>    the same effect(right now the pure zswap only tier),

Yes.

>    since zswap no longer needs to borrow a slot from
>    another device. Even so, memory.zswap.writeback still needs to
>    stay, since vswap itself can be disabled at compile time or
>    runtime, and we'd still need a way to express zswap-only behavior
>    without it. I'd like to unify the two eventually, but for now they
>    have to stay separate. I'll keep thinking about it.

The goal is to eventually make zswap depend on vswap. Once we have
that, we can deprecate zswap.writeback in favor of the tiering
interface.

>
> How do you think?
>
> thanks
> Youngjun

> > > >
> > > > Hello Yosry!
> > > >
> > > > This series does not cover zswap as a tier yet.
> > > >
> > > > My plan is to land the swap tier infrastructure together with the
> > > > first use case (cgroup-based swap control) first, and then follow
> > > > up with zswap tier support in a subsequent series, continuing the
> > > > discussions we've had above.
> > > > (I mentioned on cover letter, right above the overview section)
> > > >
> > > > Does that approach sound reasonable to you?
> > >
> > > How does swap tiering work with zswap in the current series? I assume
> > > zswap is just enabled for all devices in all tiers?
> >
> > Yes, that's correct.
> >
> > > I wonder if introducing zswap as a tier after the fact changes user-visible
> > > behavior. I guess if zswap will be introduced with a default "max"
> > > value it will more-or-less be the same behavior,
> >
> > Right, that's the plan.
> >
> > > but I would check all
> > > user-visible behaviors related to zswap (e.g. interaction with other
> > > zswap interfaces) to make sure nothing breaks or changes in a
> > > meaningful way when zswap is introduced as a tier later.
> >
> > Fair point. Let me review this more and get back to you!
>
> Please do report back what you find.
>
> 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. We also need to disallow zswap being the only
tier as that combination cannot work without vswap.

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.

> If that is not too much, we can make that part of this series.

Yeah I think it's better if we agree on the design and zswap support
before landing partial support.

On Tue, Jul 14, 2026 at 01:52:14PM -0700, Yosry Ahmed wrote:
> > > > >
> > > > > Hello Yosry!
> > > > >
> > > > > This series does not cover zswap as a tier yet.
> > > > >
> > > > > My plan is to land the swap tier infrastructure together with the
> > > > > first use case (cgroup-based swap control) first, and then follow
> > > > > up with zswap tier support in a subsequent series, continuing the
> > > > > discussions we've had above.
> > > > > (I mentioned on cover letter, right above the overview section)
> > > > >
> > > > > Does that approach sound reasonable to you?
> > > >
> > > > How does swap tiering work with zswap in the current series? I assume
> > > > zswap is just enabled for all devices in all tiers?
> > >
> > > Yes, that's correct.
> > >
> > > > I wonder if introducing zswap as a tier after the fact changes user-visible
> > > > behavior. I guess if zswap will be introduced with a default "max"
> > > > value it will more-or-less be the same behavior,
> > >
> > > Right, that's the plan.
> > >
> > > > but I would check all
> > > > user-visible behaviors related to zswap (e.g. interaction with other
> > > > zswap interfaces) to make sure nothing breaks or changes in a
> > > > meaningful way when zswap is introduced as a tier later.
> > >
> > > Fair point. Let me review this more and get back to you!
> >
> > Please do report back what you find.
> >
> > Yosry, what is needed to enable zswap as a swap tier? What will be the minimum
> > requirements for that?

Hello Yosry, Shakeel,

I have been working through this in detail at the implementation level.
For now I am adding on/off control of zswap through the tier interface.

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

This part works as you described, with no real issues.

> 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. We also need to disallow zswap being the only
> tier as that combination cannot work without vswap.

I tried to forbid this at the implementation level as you suggested
, and that is where I ran into trouble. 
A few code paths can end up with zswap as the only
tier, and they are awkward to handle.  Below is each case and what
handling it would take:

1) A write turns off the last device tier while zswap stays on.
   -> rejected with -EINVAL.  The write does not take effect.

2) The last device tier is removed via /sys/kernel/mm/swap/tiers.
   -> the file goes empty, so zswap is not shown either.

3) A cgroup has zswap and one device tier on, and that tier is removed.
   -> the cgroup's zswap entry is reset to 0, which the user never
      asked for.

4) A cgroup has zswap and device tiers on, and swapoff empties them.
   -> the cgroup's zswap entry is reset to 0.

So the problem is that in (3) and (4), memory.swap.tiers.max has to
change on its own independently of what the user wrote 
and it is not like just error handling situation as (1). 

There is also a consistency point.  memory.swap.tiers.max already
accepts a child enabling a tier that its parent has disabled: the write
succeeds, no error is returned, and the difference is resolved
internally.  The user's setting is kept as written, and only the
effective behavior is constrained.  By that logic, accepting a
zswap-only setting and guaranteeing only that it cannot do anything
would fit how the interface already behaves.

Having thought it over, I think one of these two directions would be
better than enforcing the rule as above.

1. Allow zswap-only in memory.swap.tiers.max.  As you say, it cannot
   work without vswap, so today the setting does nothing and there is
   nothing to prevent.  Once vswap/xswap lands it becomes meaningful on its
   own, with no interface change needed.

2. Expose memory.swap.tiers.max.effective, like cpuset.  We already
   track the user-set and the effective-set separately.  Exposing
   the effective one would show that a zswap-only setting is not in
   effect, giving the user visibility instead of rewriting what they
   wrote.  It would also help the parent-off/child-on case, where the
   child could see from the effective value that the tier is off.

What do you think? or any other ideas?

Thanks,
Youngjun

On Sat, Jul 18, 2026 at 8:11 AM Youngjun Park <youngjun.park@lge.com> wrote:
>
> I tried to forbid this at the implementation level as you suggested
> , and that is where I ran into trouble.
> A few code paths can end up with zswap as the only
> tier, and they are awkward to handle.  Below is each case and what
> handling it would take:
>
> 1) A write turns off the last device tier while zswap stays on.
>    -> rejected with -EINVAL.  The write does not take effect.
>
> 2) The last device tier is removed via /sys/kernel/mm/swap/tiers.
>    -> the file goes empty, so zswap is not shown either.
>
> 3) A cgroup has zswap and one device tier on, and that tier is removed.
>    -> the cgroup's zswap entry is reset to 0, which the user never
>       asked for.
>
> 4) A cgroup has zswap and device tiers on, and swapoff empties them.
>    -> the cgroup's zswap entry is reset to 0.
>
> So the problem is that in (3) and (4), memory.swap.tiers.max has to
> change on its own independently of what the user wrote
> and it is not like just error handling situation as (1).

This kind of complexity is exactly the reason I object to having zswap
as a tier in the first place. There is very little gain in having such
control for zswap in the swap tier world and it introduces a lot of
corner-case complexity.

In my mind, we should introduce a separate swap tier native memory
tier. e.g. xswap. which has a clean conceptual break from zswap
(though code can be shared). The xswap will behave like zram in terms
of tiering, but be more integrated with MM like zswap.

I think the simplest answer is just to allow zswap as a special tier,
meaning it only has an on/off control on the side. Allowing zswap as
the only tier means the cgroup won't be able to use zswap because
there are no real devices.

> There is also a consistency point.  memory.swap.tiers.max already
> accepts a child enabling a tier that its parent has disabled: the write
> succeeds, no error is returned, and the difference is resolved
> internally.  The user's setting is kept as written, and only the
> effective behavior is constrained.  By that logic, accepting a
> zswap-only setting and guaranteeing only that it cannot do anything
> would fit how the interface already behaves.
>
> Having thought it over, I think one of these two directions would be
> better than enforcing the rule as above.
>
> 1. Allow zswap-only in memory.swap.tiers.max.  As you say, it cannot
>    work without vswap, so today the setting does nothing and there is
>    nothing to prevent.  Once vswap/xswap lands it becomes meaningful on its
>    own, with no interface change needed.

Allow it on paper and accept that zswap is not a real tier. It is just
a cache in front of other swap devices.
That is what I think as well.

>
> 2. Expose memory.swap.tiers.max.effective, like cpuset.  We already
>    track the user-set and the effective-set separately.  Exposing
>    the effective one would show that a zswap-only setting is not in
>    effect, giving the user visibility instead of rewriting what they
>    wrote.  It would also help the parent-off/child-on case, where the
>    child could see from the effective value that the tier is off.

Seems more complex than it is worth.

Chris

>
> What do you think? or any other ideas?
>
> Thanks,
> Youngjun
>

> Hello Yosry, Shakeel,
>
> I have been working through this in detail at the implementation level.
> For now I am adding on/off control of zswap through the tier interface.
>
> > 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.
>
> This part works as you described, with no real issues.
>
> > 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. We also need to disallow zswap being the only
> > tier as that combination cannot work without vswap.
>
> I tried to forbid this at the implementation level as you suggested
> , and that is where I ran into trouble.
> A few code paths can end up with zswap as the only
> tier, and they are awkward to handle.  Below is each case and what
> handling it would take:
>
> 1) A write turns off the last device tier while zswap stays on.
>    -> rejected with -EINVAL.  The write does not take effect.
>
> 2) The last device tier is removed via /sys/kernel/mm/swap/tiers.
>    -> the file goes empty, so zswap is not shown either.
>
> 3) A cgroup has zswap and one device tier on, and that tier is removed.
>    -> the cgroup's zswap entry is reset to 0, which the user never
>       asked for.
>
> 4) A cgroup has zswap and device tiers on, and swapoff empties them.
>    -> the cgroup's zswap entry is reset to 0.
>
> So the problem is that in (3) and (4), memory.swap.tiers.max has to
> change on its own independently of what the user wrote
> and it is not like just error handling situation as (1).
>
> There is also a consistency point.  memory.swap.tiers.max already
> accepts a child enabling a tier that its parent has disabled: the write
> succeeds, no error is returned, and the difference is resolved
> internally.  The user's setting is kept as written, and only the
> effective behavior is constrained.  By that logic, accepting a
> zswap-only setting and guaranteeing only that it cannot do anything
> would fit how the interface already behaves.
>
> Having thought it over, I think one of these two directions would be
> better than enforcing the rule as above.
>
> 1. Allow zswap-only in memory.swap.tiers.max.  As you say, it cannot
>    work without vswap, so today the setting does nothing and there is
>    nothing to prevent.  Once vswap/xswap lands it becomes meaningful on its
>    own, with no interface change needed.
>
> 2. Expose memory.swap.tiers.max.effective, like cpuset.  We already
>    track the user-set and the effective-set separately.  Exposing
>    the effective one would show that a zswap-only setting is not in
>    effect, giving the user visibility instead of rewriting what they
>    wrote.  It would also help the parent-off/child-on case, where the
>    child could see from the effective value that the tier is off.
>
> What do you think? or any other ideas?

Hmm yes, seems like enforcing this rule comes with a lot of complexity
for little gain. It's possible today to enable zswap without adding
any swap devices, which would render zswap useless anyway. I suppose
in the same way, we can just do (1) and allow users to disallow all
tiers except zswap for a cgroup, which would effectively disable zswap
in the same way (albeit a bit less clear). We can document this
clearly in the memcg docs.

Shakeel, any objections to this?

On Mon, Jul 20, 2026 at 11:27:56AM -0700, Yosry Ahmed wrote:
> > Hello Yosry, Shakeel,
> >
> > I have been working through this in detail at the implementation level.
> > For now I am adding on/off control of zswap through the tier interface.
> >
> > > 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.
> >
> > This part works as you described, with no real issues.
> >
> > > 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. We also need to disallow zswap being the only
> > > tier as that combination cannot work without vswap.
> >
> > I tried to forbid this at the implementation level as you suggested
> > , and that is where I ran into trouble.
> > A few code paths can end up with zswap as the only
> > tier, and they are awkward to handle.  Below is each case and what
> > handling it would take:
> >
> > 1) A write turns off the last device tier while zswap stays on.
> >    -> rejected with -EINVAL.  The write does not take effect.
> >
> > 2) The last device tier is removed via /sys/kernel/mm/swap/tiers.
> >    -> the file goes empty, so zswap is not shown either.
> >
> > 3) A cgroup has zswap and one device tier on, and that tier is removed.
> >    -> the cgroup's zswap entry is reset to 0, which the user never
> >       asked for.
> >
> > 4) A cgroup has zswap and device tiers on, and swapoff empties them.
> >    -> the cgroup's zswap entry is reset to 0.
> >
> > So the problem is that in (3) and (4), memory.swap.tiers.max has to
> > change on its own independently of what the user wrote
> > and it is not like just error handling situation as (1).
> >
> > There is also a consistency point.  memory.swap.tiers.max already
> > accepts a child enabling a tier that its parent has disabled: the write
> > succeeds, no error is returned, and the difference is resolved
> > internally.  The user's setting is kept as written, and only the
> > effective behavior is constrained.  By that logic, accepting a
> > zswap-only setting and guaranteeing only that it cannot do anything
> > would fit how the interface already behaves.
> >
> > Having thought it over, I think one of these two directions would be
> > better than enforcing the rule as above.
> >
> > 1. Allow zswap-only in memory.swap.tiers.max.  As you say, it cannot
> >    work without vswap, so today the setting does nothing and there is
> >    nothing to prevent.  Once vswap/xswap lands it becomes meaningful on its
> >    own, with no interface change needed.
> >
> > 2. Expose memory.swap.tiers.max.effective, like cpuset.  We already
> >    track the user-set and the effective-set separately.  Exposing
> >    the effective one would show that a zswap-only setting is not in
> >    effect, giving the user visibility instead of rewriting what they
> >    wrote.  It would also help the parent-off/child-on case, where the
> >    child could see from the effective value that the tier is off.
> >
> > What do you think? or any other ideas?
> 
> Hmm yes, seems like enforcing this rule comes with a lot of complexity
> for little gain. It's possible today to enable zswap without adding
> any swap devices, which would render zswap useless anyway. I suppose
> in the same way, we can just do (1) and allow users to disallow all
> tiers except zswap for a cgroup, which would effectively disable zswap
> in the same way (albeit a bit less clear). We can document this
> clearly in the memcg docs.
> 
> Shakeel, any objections to this?

Nopes, no objections.

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.

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

Youngjun, what do you think? Is this reasonable amount of additional work or do
you envision some complexity here?

> 
> > If that is not too much, we can make that part of this series.
> 
> Yeah I think it's better if we agree on the design and zswap support
> before landing partial support.

On Tue, Jul 14, 2026 at 3:26 PM Shakeel Butt <shakeel.butt@linux.dev> 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.

You shouldn't need to hard code that priority for zswap. Zswap, if you
make it a tier, it is a special case. It is different than other swap
tier devices because when you search for a swap slot, you don't need
to search zswap as a swap device now. So the priority of the swap
device does not even come into play. Internally, zswap is already
hardcoded to perform before the underlying swap device. It is not an
order you can change in any way.

So we don't need that priority number. Just reserve a special name for zswap.

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

There is no need to do anything special now. The current zswap is bind
to the underlying swap device. That is unless we use vswap/Xswap/ghost
swapfile.

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

Agree as well

Chris

>
> Youngjun, what do you think? Is this reasonable amount of additional work or do
> you envision some complexity here?
>
> >
> > > If that is not too much, we can make that part of this series.
> >
> > Yeah I think it's better if we agree on the design and zswap support
> > before landing partial support.

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.

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

Thanks,
Youngjun

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.

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

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.

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.

Chris

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?

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

On Tue, Jul 14, 2026 at 3:26 PM Shakeel Butt <shakeel.butt@linux.dev> 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.
>
> > 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.

At least on the memcg side we need to disallow writing 0 for all tiers
except zswap. Not sure about the global tier configurations.

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.

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