Re: Path forward for Virtualized Swap?
From: Chris Li
Date: Tue Sep 22 2026 - 12:49:58 EST
On Tue, Sep 22, 2026 at 4:59 AM Rik van Riel <riel@xxxxxxxxxxx> wrote:
>
> On Tue, 2026-09-22 at 03:32 -1000, Chris Li wrote:
> > On Mon, Sep 21, 2026 at 8:53 AM Rik van Riel <riel@xxxxxxxxxxx>
> > wrote:
> > >
> > > On Mon, 2026-09-21 at 08:10 -1000, Chris Li wrote:
> > > > On Mon, Sep 21, 2026 at 6:40 AM Rik van Riel <riel@xxxxxxxxxxx>
> > > > wrote:
> > > > >
> > > > > On Mon, 2026-09-21 at 06:31 -1000, Chris Li wrote:
> > > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > > Here's my desktop system right now. The amount
> > > > > of Zswapped is more than twice AnonPages, and
> > > > > the system stays perfectly usable.
> > > > >
> > > > > $ grep -E '(Anon|Zswap|GPU|Swap)' /proc/meminfo
> > > > > SwapCached: 252340 kB
> > > > > SwapTotal: 41523604 kB
> > > > > SwapFree: 9802088 kB
> > > > > Zswap: 8812236 kB
> > > > > Zswapped: 24927876 kB
> > > > > AnonPages: 11615760 kB
> > > > > AnonHugePages: 1402880 kB
> > > > > GPUActive: 13112428 kB
> > > > > GPUReclaim: 95980 kB
> > > > >
> > > > > This is also an example where I cannot really
> > > > > predict how much zswap space I need, because
> > > > > that depends on what AI model is loaded,
> > > > > which drives the GPUActive number, as well
> > > > > as the number of browser tabs.
> > > > >
> > > > > The system is perfectly responsive.
> > > >
> > > > Great, that is getting somewhere. We are talking about actual
> > > > usage.
> > > > I
> > > > really appreciate that.
> > > >
> > > > May I ask what the total amount of memory (RAM) in your system
> > > > is?
> > > >
> > > > I am not asking zswap compare to ANA memory. I want to get the %
> > > > of
> > > > the total RAM.
> > > > I assume your desktop has more than 8G of RAM, right?
> > >
> > > Right now it has 64GB of memory.
> >
> > That is exactly my point. You are running 1/8 = 12.5% system ram.
> >
>
> > My point is that, I haven't seen a case where the application is
> > still
> > usable with a reasonable SLO when 100% of RAM is zswapped out.
>
> In my numbers above, the applications have 11.6GB
> AnonPages, and 25GB Zswap.
>
> That is about 68% of anon memory stored in zswap. Not 8%.
>
> Out of (anon + zswap), zswap takes up 43%
>
> Can we at least agree on the observed numbers?
Yes, I can agree on what you observed. You are using anon + zswap on
that app alone. That is not what I originally asked.
My original request was for the whole system: what percentage of the
total system RAM size has been swapped out to zswap.
Because when you have 100% of zswap out, it will likely trigger
different kernel code path on allocating memory. You might suffer
global memory pressure you did not observe in the single app memory
pressure case.
> > >
>
> > > hen the amount needed to fit a workload
> > > does not have a positive correlation with
> > > the amount of system memory?
> >
> > It absolutely has a positive correlation with % of the system memory
> > based on my experience. The % of memory swap out has a very positive
> > correlation with the thrashing on the application.
>
> The applications thrash much harder once zswap flows
> over onto disk! Out of all the swap options available,
> zswap is the fastest, lowest latency one.
I agree zswap is the fastest one, no question about it. In our
deployment, we have only used zswap for a very long time. Things might
change now. My observation is that, even with zswap, when 100% of
system RAM is swapped out, the application suffers greatly. There is a
reason why we only have 7-10% system RAM swapped out. There were many
OMG in the past that established this boundary for us. We did not make
up that number; it came from the real data feedback from the fleet.
So again I question the real data point for the 100% RAM swap out
case. Do we even know what the system looks like at that point?
>
> Forcing things out to disk "because too much zswap
> is slow" could just slow things down further.
I did not think zswap was slow. I assumed the swap was only zswap, and
that even 100% usage was too much.
> Now, there is probably some upper bound where
> the zswap pool itself starts to hurt performance
> because it's crowding the applications out of
> memory, but that could be quite large.
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.
Chris