Re: [PATCH v3 1/4] mm/zswap: Make shrink_worker writeback cursor per-memcg

[Hao Jia]

On 2026/6/9 02:01, Nhat Pham wrote:
> On Mon, Jun 8, 2026 at 9:48 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > > But OTOH, this does seem like a recipe for inefficient reclaim. We
> > > might exhaust hotter memory of a cgroup while sparing colder memory of
> > > another cgroup... But maybe if they're all cold anyway, then who
> > > cares, and eventually you'll get to the cold stuff of other child?
> >
> > Forgot to respond to this part, the unfairness is limited to the batch
> > size per-invocation, so it should be fine as long as you don't divide
> > the amount over 100 iterations for some reason. Also yes, all memory
> > in zswap is cold, the relative coldness is not that important (e.g.
> > compared to relative coldness during reclaim).
>
> Ok then yeah, I think we should shelve per-memcg cursor for the next
> version. Down the line, if we have more data that unfairness is an
> issue, we can always fix it. One step at a time :)

Thanks a lot to Yosry, Nhat, and Shakeel for the great suggestions!

Let me summarize what I plan to do in the next version to make sure we 
are on the same page:

 - 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 keeping the writeback behavior in the zswap_store() path unchanged.

Please let me know if I missed or misunderstood anything. Thanks again 
for clearing things up!

Thanks，
Hao