Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback

[Nhat Pham]

On Wed, Jun 3, 2026 at 10:58 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Wed, Jun 03, 2026 at 07:22:36PM +0800, Hao Jia wrote:
> >
> >
> > On 2026/5/30 09:40, Yosry Ahmed wrote:
> > > On Fri, May 29, 2026 at 12:58:09PM -0700, Nhat Pham wrote:
> > > > On Tue, May 26, 2026 at 4:46 AM Hao Jia <jiahao.kernel@xxxxxxxxx> wrote:
> > > > >
> > > > > From: Hao Jia <jiahao1@xxxxxxxxxxx>
> > > > >
> > > > > Zswap currently writes back pages to backing swap reactively, triggered
> > > > > either by the shrinker or when the pool reaches its size limit. There is
> > > > > no mechanism to control the amount of writeback for a specific memory
> > > > > cgroup. However, users may want to proactively write back zswap pages,
> > > > > e.g., to free up memory for other applications or to prepare for
> > > > > memory-intensive workloads.
> > > > >
> > > > > Introduce a "zswap_writeback_only" key to the memory.reclaim cgroup
> > > > > interface. 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 100MB of pages from zswap to the backing swap
> > > > >    echo "100M zswap_writeback_only" > memory.reclaim
> > > >
> > > > Hmmm, so this 100MB is the pre-compression size? i.e if this 100 MB
> > > > compresses to 25 MB, then you're only freeing 25 MB?
> > > >
> > > > I'm ok-ish with this, but can you document it?
> > >
> > > That's a good point. I think pre-compressed size doesn't make sense to
> > > be honest. We should care about how much memory we are actually trying
> > > to save by doing writeback here.
> > >
> > > The pre-compressed size is only useful in determining the blast radius,
> > > how many actual pages are going to have slower page faults now. But
> > > then, I don't think there's a reasonable way for userspace to decide
> > > that.
> > >
> > > I understand passing in the compressed size is tricky because we need to
> > > keep track of the size of the compressed pages we end up writing back,
> > > but it should be doable.
> >
> > Agreed. Using pre-compressed size is probably easier to implement. IIRC,
> > interfaces like ZRAM writeback_limit are also calculated using the
> > pre-compressed size.
> >
> > I'll clarify this in the documentation in the next version.
> >
> > >
> > > If we really want pre-compressed size here, then yes we need to make it
> > > very clear, and I vote that we use a separate interface in this case
> > > because memory.reclaim having different meanings for the amount of
> > > memory written to it is extremely counter-intuitive.
> > >
> > Agree. This would indeed break the semantics of memory.reclaim. I will use a
> > separate interface for proactive writeback in the next version.
>
> But doesn't it make more sense to specify the compressed size, which is
> ultimately the amount of memory you actually want to reclaim.
>

I personally prefer compressed size to pre-compressed size. That's
kinda what user cares about, no?

One thing we can do is let users prescribe a compressed size, but
internally, we can multiply that by the average compression ratio.
That gives us a guesstimate of how many pages we need to reclaim, and
you can follow the rest of your implementation as is (perhaps with
short-circuit when we reach the goal with fewer pages reclaimed).