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

[Yosry Ahmed]

On Tue, Jun 09, 2026 at 11:18:26AM +0800, Hao Jia wrote:
> 
> 
> 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!

Sorry for the late response, yes I think this makes sense. However, I
have some comment about how this interacts with swap tiering, let me
reply to the other thread.

> 
> Thanks，
> Hao