Re: [PATCH v6 00/12] Virtual Swap Space (Swap Table Edition)

[Nhat Pham]

On Wed, Oct 21, 2026 at 7:36 PM Gregory Price (Meta) <gourry@xxxxxxxxxx> wrote:
>
> On 2026-10-20 23:03 -0700, Nhat Pham wrote:
> > B. Semi-synthetic Workloads (memhog, usemem, kernel build)
> > ==========================================================
> >
> > All values are mean +/- standard deviation across rounds.
> >
> > Test system: x86_64, 52 cores, 64 GB swapfile for all 3 benchmarks.
> > Swap backend: zswap (zstd) with the traditional active/inactive LRU. We
> > focus on zswap here because it is the motivating use case for vswap.
> >
>
> I get that the motivation is zswap, but it would be nice to have
> disk-swap performance numbers here as well right in the cover.
>
> If only because...

I probably should test it regardless, but likely there will be no
difference in performance numbers. Right now for straight disk
swapping we incur 0 overhead, because I just bypass the virtualization
layer :) There just isn't any feature for me to entertain vswap+disk
swap quite yet (it might come soon-ish though).

Vswap's physical swapfile backend is only used for cgroups that
support zswap (for zswap writeback and fallback if vswap fails to
allocate or zswap rejects the page etc.).

For the older version, I put vswap in front of all swap backends. Disk
swap sees no regression, but Kairui found some regression with fast
in-memory swapfile (pmem). I reproduced it with zram, and I think I
closed that gap in my own testing, but Kairui did not test the fixed
version AFAICT, and I also don't have his full suite, only the ones he
quoted.

(Btw, Kairui, could you publish your full suite, or at least the full
set of testing parameters? I would like to hammer the thing myself to
expose bugs etc.).

>
> > For each benchmark, we test 3 kernels:
> > * Baseline: mm-unstable, no vswap patches.
> > * VSS off: vswap series applied, vswap=off, to verify that there is no
> >   regression to existing swap paths when we disable vswap.
> > * VSS on: vswap series applied, vswap=on.
> >
>
> If the numbers you presented carry through, I'm left wondering why this
> is a boot option and not a build option.  I rather dislike the boot
> option compromise in general - but other reasoning aside, if there's no
> performance impact, then I don't see why it shouldn't be the default.

That's a good point yeah. Lemme think about it. I added the boot param
before I decided to bypass vswap for physical swapfile by default...

>
> ~Gregory
>
> --
> Gregory Price (Meta) <gourry@xxxxxxxxxx>