Re: Path forward for Virtualized Swap?

[Shakeel Butt]

On Tue, Sep 22, 2026 at 09:44:37PM -1000, Chris Li wrote:
> 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.

Johannes has already answered this very clearly but let me talk about your other
claim.

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

What do you mean here by "break our deployment"? We are talking about
memory.swap usage and limits here. Google is still on v1 and using memsw
usage and limit and I don't see how vswap is breaking memsw?

Are you making these false claims just to derail the conversation?