Some swap backends are useful for deliberate cold-page offload but are poor dependencies for ordinary reclaim under acute memory pressure. Swap on ZFS zvols is an existing example, with documented deadlocks under memory pressure [3]. Compressed swap is another attractive target: accepting a write may require memory for compression or storage even when logical swap slots remain free.
This series adds an offload-only swap-area policy for such deployments, alongside a conventional swap reserve for pressure reclaim. Proactive offloading is already established by TMO/Senpai [4], which uses pressure feedback to offload cold pages to compressed memory or SSDs. DAMON_RECLAIM [5] also uses free-memory watermarks to suspend proactive reclaim under severe pressure. These control when reclaim runs; this RFC restricts which swap areas ordinary reclaim may write, including through retained swap entries. The existing memory.zswap.writeback control [6] restricts backing-swap writes per cgroup, rather than reserving individual swap areas for explicitly admitted offload. The minimum contract is that ordinary reclaim must not initiate a new, non-zero backend write to an offload-only area. Reads, swapoff, zero-page metadata, architecture preparation, and I/O that was already admitted remain valid. If no eligible swap remains, existing reclaim and OOM behaviour applies. This RFC does not promise a performance result or define a new workload policy. Cgroup v2 memory.reclaim and per-node reclaim establish admission. Manual MGLRU eviction currently does too, but its debugfs interface is not stable ABI. Ordinary direct reclaim, kswapd, MADV_PAGEOUT and DAMON reclaim do not gain access. This is an explicit operator policy; the kernel does not measure physical headroom or automatically classify backends. The three patches are based on mm-new as refreshed on 11 September, at 995829088503: 1. The complete swap-area policy, including eligible-capacity accounting and recovery of eligible cache entries. 2. zram03/zram04 coverage for reclaim routing, zswap bypass, discard policy and file workingset activation. 3. zram05 coverage for retained swap entries, including ordinary-write refusal, proactive recovery, data integrity and checked teardown. The implementation is intended to make these questions reviewable: 1. Should pressure eligibility be a durable property activated with the physical swap area, or should it be selected late during backend migration? 2. Do provenance, allocation filtering, eligible capacity, and retained-entry refusal provide a useful minimum contract for userspace and controllers? 3. Is redirtying or activating a retained dirty folio, with possible churn or OOM, acceptable, or is backend migration a prerequisite? 4. How should persistent activation fail closed and remain auditable when /proc/swaps and swapon --show do not expose the policy? 5. Should an ineligible fast-path cluster be invalidated immediately, and should an offload-only area recover its own cache entries based on eligible fullness rather than global swap fullness? 6. Should the workingset activation heuristic continue to count offload-only capacity when pressure reclaim cannot allocate from it? Build checks passed on x86 with i915 built-in or modular, and with swap or memory cgroups disabled. The affected arm64 MTE objects also compiled. The routing and workingset tests passed in x86 QEMU guests. In the retained-entry test, ordinary reclaim wrote nothing to offload-only swap; proactive reclaim then wrote the dirty folio, and all data verified correctly. With the write guard removed, the same test failed because ordinary reclaim wrote to the offload-only area. Persistent fstab encoding remains unsettled. When hibernation is about to save an image, an active offload-only area named by resume= is rejected as the image target with -ENODEV. Virtual Swap Space v4 [1] separates swap entries from their physical backing, while swap tiers v10 [2] proposes per-cgroup backend selection. These raise the question of whether offload eligibility belongs to physical swap areas or a later placement decision; this RFC does not assume those interfaces are settled. An explicit-only util-linux companion implementing swapon --offload-only is prepared for separate submission. Feedback on the eligibility contract, its placement in the swap stack, and the unresolved ABI and reclaim-policy questions would be welcome. [1] https://patchew.org/linux/[email protected]/ [2] https://patchew.org/linux/[email protected]/ [3] https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html#using-a-zvol-for-a-swap-device-on-linux [4] https://engineering.fb.com/2022/06/20/data-infrastructure/transparent-memory-offloading-more-memory-at-a-fraction-of-the-cost-and-power/ [5] https://www.kernel.org/doc/html/latest/admin-guide/mm/damon/reclaim.html [6] https://www.kernel.org/doc/html/latest/admin-guide/mm/zswap.html Matthias Goergens (3): mm: restrict offload-only swap to proactive reclaim selftests: zram: cover offload-only swap policy selftests: zram: cover retained offload-only entries Documentation/mm/swap.rst | 87 ++++ drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 6 +- drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 +- drivers/gpu/drm/panthor/panthor_gem.c | 2 +- drivers/gpu/drm/ttm/ttm_backup.c | 2 +- drivers/gpu/drm/xe/tests/xe_bo.c | 2 +- include/linux/swap.h | 29 +- include/linux/vm_event_item.h | 1 + mm/memcontrol.c | 20 +- mm/page_io.c | 24 +- mm/swapfile.c | 126 +++++- mm/vmscan.c | 31 +- mm/vmstat.c | 1 + tools/testing/selftests/zram/.gitignore | 2 + tools/testing/selftests/zram/Makefile | 4 +- tools/testing/selftests/zram/config | 10 +- tools/testing/selftests/zram/swap_offload.c | 402 ++++++++++++++++++ .../selftests/zram/workingset_offload.c | 206 +++++++++ tools/testing/selftests/zram/zram03.sh | 166 ++++++++ tools/testing/selftests/zram/zram04.sh | 149 +++++++ tools/testing/selftests/zram/zram05.sh | 360 ++++++++++++++++ tools/testing/selftests/zram/zram_lib.sh | 28 ++ 23 files changed, 1620 insertions(+), 42 deletions(-) create mode 100644 tools/testing/selftests/zram/swap_offload.c create mode 100644 tools/testing/selftests/zram/workingset_offload.c create mode 100755 tools/testing/selftests/zram/zram03.sh create mode 100755 tools/testing/selftests/zram/zram04.sh create mode 100755 tools/testing/selftests/zram/zram05.sh base-commit: 9958290885035431e2494159f555e332c3c14906 -- 2.55.0
