Re: [PATCH v3 2/2] mm/zswap: Support batch writeback in shrink_memcg()

Nhat Pham <[email protected]> Wed, 5 Aug 2026 11:13:25 -0700
Newsgroups gmane.linux.documentation,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.kernel.stable
Message-ID <CAKEwX=OuXHCV1G67AgJa+S42O0S+u+CGyOKcg9HqJ_6Pu_=5hg@mail.gmail.com>
On Tue, Aug 4, 2026 at 11:21 PM Hao Jia <[email protected]> wrote:
>
>
>
> On 2026/8/1 08:31, Hao Jia wrote:
> >
> >
> > On one hand, this avoids scanning the same entry multiple times within a
> > single pass. Since the second-chance algorithm rotates referenced
> > entries to the tail of the LRU, entries on nodes with a large number of
> > zswap entries require at least two shrink_memcg() calls to be written
> > back, whereas entries on nodes with fewer entries might get written back
> > in a single shrink_memcg() call instead. On the other hand, we also

Same thing happens if you have more entries, no? Say you have 64
entries and 96 entries in node 1 and node 2, respectively. Then you
need to go to round 3 to reclaim an entry in node 1, and round 4 for
node 2. What's special about 1/2 rounds vs 3/4 rounds?

I think it's probably fine to just pass SWAP_CLUSTER_MAX as nr_to_walk
- we're applying equal amount of reclaim pressure to 2 nodes. Without
prior information, seems like a reasonable strategy to me. I think
what you did is already a pretty big improvements to status quo - we
can always add more fine tuning on top of it later if needs be.

> > avoid spinning repeatedly on entries that fail writeback.

SWAP_CLUSTER_MAX is 32, so I assume it's not going to spin for a
terribly long amount of time?