Re: Path forward for Virtualized Swap?

[Chris Li]

On Tue, Sep 22, 2026 at 7:54 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
>
> On Sun, Sep 20, 2026 at 5:13 PM Chris Li <chrisl@xxxxxxxxxx> wrote:
> >
> > That is not what I have in mind. The example I have in mind is that
> > zswap is charged to swap counters. Changing that behavior will break
> > our current deployment and that of many other. Kairui give some
> > example as well. That behavior should not change.
>
> We already have a knob to select vswap. Users can turn it off
> initially, and/or update their software to handle the transition
> based on this knob.
>
> Otherwise, you'd never be able to introduce any behavior into the
> kernel. Hugetlb accounting/charging is a new behavior, and there were
> softwares written before that assumed hugetlb usage is not charged. If
> it's not a good argument to block the implementation of hugetlb
> accounting then, it's not a good argument now.

My original intent is that 200% of RAM for zswap is too much.

It seems you are talking about a different topic: the vswap charging issue.
There is a golden rule that we should follow: don't break existing
users. At least with the same persistence, this rule should apply
universally.
In the swap tiers discussion, the UAPI was such a big deal that we
couldn't implement new UAPI. On the other hand here we argue for
liberally changing user-space visible behavior.

BTW, I already shared that changing swap counter charging will break
our and others' existing deployments.

Chris