Re: Path forward for Virtualized Swap?

[Chris Li]

On Mon, Sep 21, 2026 at 5:16 AM Rik van Riel <riel@xxxxxxxxxxx> wrote:
>
> On Sun, 2026-09-20 at 23:43 -1000, Chris Li wrote:
> >
> > I am sorry, that is not actual user usage. You need to start from an
> > actual usage case: I have a workload X, only want to give limit Y for
> > the cgroup jobs but with Z SLO requirement. That kind of actual usage
> > requirement.
>
> Limiting how much anonymous memory can be zswapped
> does not guarantee an SLO, though.

Nothing can guarantee an SLO. It is a safeguard we used. Those are
existing use cases.

> We have seen plenty of examples in practice of
> workloads that have swap DISABLED, and are still
> thrashing, because part of the working set of
> that program is in the page cache, and that still
> gets evicted.

I can only imagine adding more zswap will make the workload worse, not better.

>
> The way you can guarantee the workload is not
> thrashing is to limit the total (anon + file
> cache) address space of the program to within
> some size.
>
> Anything else is not a guarantee.
>
> What is it you are actually asking for?

Give me some real-world examples of people hitting this kind of limit.
e.g. MAX(%)  > 100% and still have a usesable system. I suspect that
with 100% zswap usage, the system becomes unusable. Please show me a
real world case that proves me wrong.

All your use cases are hypothetical, or someone in a corner of the
world is going to have a problem. Give me one usage case I can repeat
and test validate.
You can't even do that, the burden is on you.

In the kernel, we don't break user space behavior for no good reason.

Chris