Re: Path forward for Virtualized Swap?

[Chris Li]

On Tue, Sep 22, 2026 at 5:43 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
>
> On Tue, Sep 22, 2026 at 05:23:31AM -1000, Chris Li wrote:
> > In my experiment, 100% is already way above that bound, which is why
> > I'm curious about your data point. How do you run and test your system
> > at 100%? Please correct me if I am wrong, but it looks like you
> > haven't.
>
> You're conflating machine size with workingset residency.
>
> Rik showed an example where the compressed set was twice as large as
> the anon set, and it worked fine. And why is that surprising?

Where did I say surprised? I am just saying that is not the metric I
am looking for.

> We know many applications have long tails of cold pages. Idle tmpfs
> files and shmem segments. Things that get rarely used. memcache style
> workloads have a small, hot index and a huge data segment with poor
> access locality. Even if large parts of it are in compressed space
> that's better than storage fetches.

So what is the max (%) in your fleet based on my metric definition?
>
> Your "this will thrash after 7-10%" is an average based on common
> workingsets that are actually hot. It doesn't mean there aren't cases
> that benefit from much higher overcommit.

That is what I have been repeatedly asking for regarding your
deployment setup. What is the amount of memory swapped out to zswap
relative to the total system RAM? This should be a simple query on
your end. Nobody has been able to provide a data point where that
percentage reaches 100.

> Why even get into this? Why even try to find some universal limit on
> something that just costs memory anyway, when memory containment is
> already a solved problem?

Because I suspect that if that number goes above 100 the machine is
unusable. If this statement is true, then nobody would want to zswap
100% of the RAM. I don't need to preserve that much a space. Asking
for too large a value is ridiculous.

Chris