Linux Documentation
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Hao Jia <jiahao.kernel@gmail.com>
Cc: akpm@linux-foundation.org, tj@kernel.org, hannes@cmpxchg.org,
	shakeel.butt@linux.dev, mhocko@kernel.org, yosry@kernel.org,
	mkoutny@suse.com, nphamcs@gmail.com, chengming.zhou@linux.dev,
	roman.gushchin@linux.dev, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	Hao Jia <jiahao1@lixiang.com>
Subject: Re: [PATCH v4 0/5] mm/zswap: Implement per-cgroup proactive writeback
Date: Sun, 21 Jun 2026 12:20:51 +0800	[thread overview]
Message-ID: <CAAAF57B-7DE9-45EA-8AB6-DE6CFAF60F47@linux.dev> (raw)
In-Reply-To: <20260618044857.69439-1-jiahao.kernel@gmail.com>



> On Jun 18, 2026, at 12:48, Hao Jia <jiahao.kernel@gmail.com> wrote:
> 
> From: Hao Jia <jiahao1@lixiang.com>
> 
> Zswap currently writes back pages to backing swap reactively, triggered
> either by the shrinker or by the pool reaching its size limit. Although
> proactive memory reclaim can automatically write back a portion of zswap
> pages via the shrinker, it cannot explicitly control the amount of
> writeback for a specific memory cgroup. Moreover, proactive memory reclaim
> may not always be triggered during a steady state.
> 
> In certain scenarios, it is desirable to trigger writeback in advance to
> free up memory. For example, users may want to prepare for an upcoming
> memory-intensive workload by flushing cold memory to the backing storage
> when the system is relatively idle.
> 
> This patch series introduces a "zswap_writeback_only" key to memory.reclaim
> cgroup interface, allowing users to proactively write back cold compressed
> data from zswap to the backing swap device. When specified, this key
> bypasses standard memory reclaim and exclusively performs proactive zswap
> writeback up to the requested budget. If omitted, the default reclaim
> behavior remains unchanged.
> 
> Example usage:
>  # Write back 10MB of compressed data from zswap to the backing swap
>  echo "10M zswap_writeback_only" > memory.reclaim

I’m not entirely sure if other candidate names were already brought up
in previous discussions, so my apologies if I'm repeating something here!
I do think expanding memory.reclaim is a great approach. That said, I
was wondering if we could make the interface a bit more concise while
keeping it flexible for future extensions.

Essentially, what we want is to control the specific targets of the reclaim
process—such as file, anon, or zswap. What do you think about using
something like "source=zswap"? For instance, if we want to reclaim 10M from
zswap, the command would look like this:

	echo "10M source=zswap" > memory.reclaim

If we only want to reclaim 10M from file pages, we could easily extend the
syntax:

	echo "10M source=file" > memory.reclaim

And of course, we could even combine them down the road:

	echo "10M source=anon,file" > memory.reclaim

to only reclaim anon and file but bypass zswap.

Just some thoughts of mine.

Muchun,
Thanks

> 
> Patch 1: Extend shrink_memcg() to support batch writeback based on a
>  compressed-size budget and update its return value semantics, thereby
>  improving the writeback efficiency in the shrink_worker() path.
> Patch 2: Extract the memcg iteration and writeback loop into helper
>  functions to prepare for proactive writeback.
> Patch 3: Extend the memory.reclaim cgroup v2 interface with a new
>  "zswap_writeback_only" key, allowing users to trigger proactive zswap
>  writeback up to a requested budget.
> Patch 4: Add the zswpwb_proactive_b stat to track the compressed bytes
>  of proactive writeback for better monitoring and tuning.
> Patch 5:
>  Add tests for zswap proactive writeback.
> 
> v3->v4:
>  - Drop the per-memcg cursor and keep the root cgroup cursor
>    (zswap_next_shrink) logic intact.
>  - Stick to using the zswap_writeback_only key, and change the proactive
>    writeback size to use the compressed size.
>  - Consolidate and reuse the logic between shrink_worker() and
>    shrink_memcg(). Enable batch writeback in the shrink_worker() path,
>    while maintaining a low writeback budget in the zswap_store() path.
> 
> v2->v3:
>    - Align the return value of zswap_proactive_writeback() with
>      memory.reclaim and update the corresponding documentation accordingly.
>    - Resolve conflicts in test_zswap.c on the mm-unstable branch.
>    - Enhance the zswap proactive writeback selftests to guard against potential
>      future regressions.
> 
> v1->v2:
>    - As suggested by Yosry and Nhat, extend the memory.reclaim cgroup v2
>      interface with a "zswap_writeback_only" key instead of adding a new
>      dedicated cgroup interface.
>    - Update the zswap documentation and add selftests for proactive writeback.
> 
> [v3] https://lore.kernel.org/all/20260526114601.67041-1-jiahao.kernel@gmail.com
> [v2] https://lore.kernel.org/all/20260525122242.36127-1-jiahao.kernel@gmail.com
> [v1] https://lore.kernel.org/all/20260511105149.75584-1-jiahao.kernel@gmail.com
> 
> Hao Jia (5):
>  mm/zswap: Extend shrink_memcg() writeback capability
>  mm/zswap: Factor writeback loop out of shrink_worker()
>  mm/zswap: Implement proactive writeback
>  mm/zswap: Add per-memcg stat for proactive writeback
>  selftests/cgroup: Add tests for zswap proactive writeback
> 
> Documentation/admin-guide/cgroup-v2.rst     |  22 +-
> Documentation/admin-guide/mm/zswap.rst      |  11 +-
> include/linux/memcontrol.h                  |   1 +
> include/linux/zswap.h                       |   7 +
> mm/memcontrol.c                             |   3 +
> mm/vmscan.c                                 |  14 +
> mm/zswap.c                                  | 322 +++++++++++++++-----
> tools/testing/selftests/cgroup/test_zswap.c | 153 +++++++++-
> 8 files changed, 456 insertions(+), 77 deletions(-)
> 
> -- 
> 2.34.1
> 


  parent reply	other threads:[~2026-06-21  4:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18  4:48 [PATCH v4 0/5] mm/zswap: Implement per-cgroup proactive writeback Hao Jia
2026-06-18  4:48 ` [PATCH v4 1/5] mm/zswap: Extend shrink_memcg() writeback capability Hao Jia
2026-06-18  4:48 ` [PATCH v4 2/5] mm/zswap: Factor writeback loop out of shrink_worker() Hao Jia
2026-06-18  4:48 ` [PATCH v4 3/5] mm/zswap: Implement proactive writeback Hao Jia
2026-06-18  4:48 ` [PATCH v4 4/5] mm/zswap: Add per-memcg stat for " Hao Jia
2026-06-18  4:48 ` [PATCH v4 5/5] selftests/cgroup: Add tests for zswap " Hao Jia
2026-06-21  4:20 ` Muchun Song [this message]
2026-06-22  6:08   ` [PATCH v4 0/5] mm/zswap: Implement per-cgroup " Hao Jia
2026-06-22 10:04     ` Youngjun Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAAF57B-7DE9-45EA-8AB6-DE6CFAF60F47@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=jiahao.kernel@gmail.com \
    --cc=jiahao1@lixiang.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=nphamcs@gmail.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=tj@kernel.org \
    --cc=yosry@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox