Re: Path forward for Virtualized Swap?

[Nhat Pham]

On Tue, Sep 22, 2026 at 10:15 AM Rik van Riel <riel@xxxxxxxxxxx> wrote:
>
> On Mon, 2026-09-21 at 06:11 -1000, Chris Li wrote:
> > On Mon, Sep 21, 2026 at 2:53 AM Gregory Price <gourry@xxxxxxxxxx>
> > wrote:
> >
> > >
> > > You can't know the compressibility of memory until after you
> > > compress
> > > it, and requiring a user to predict the future by forcing them to
> > > limit
> > > the total amount of workload compressibility does not scale with
> > > the
> > > number of workloads of variable compressibility of data.
> >
> > You likely just need to pull a SQL query on your fleet to get that
> > number.
>
> This feature is not being developed for just one
> user. It has to work for everybody.
>
> >
> > > That should tell you that your model of reasoning about this issue
> > > is
> > > ill-suited to address the problem.
> >
> > That is what I'm suspecting. Nobody in a sane mind would want to
> > zswap
> > 100% of the RAM and maintain reasonable SLO.
> >
> It could make a lot of sense to have some default
> limit upstream, that says the zswap pool is not
> allowed to take more than half of memory, because
> at that point the compressed content will be
> crowding other things out of memory.

I actually am skeptical of gating zswap usage (both pre- and
post-compression), but I would like to note that for post-compression
size, we already have that knob for zswap, default to 20% of physical
RAM.