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?