Re: Path forward for Virtualized Swap?

[Kairui Song]

On Tue, Oct 13, 2026 at 1:27 PM Chris Li <chrisl@xxxxxxxxxx> wrote:
>
> On Mon, Oct 5, 2026 at 5:19 AM David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> >
> > On 9/22/26 15:38, Chris Li wrote:
> > > On Mon, Sep 21, 2026 at 8:56 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote:
> > >>
> > >> On Fri, Sep 18, 2026 at 11:50 PM Chris Li <chrisl@xxxxxxxxxx> wrote:
> > >>> No that time slot is too late for Asia developers. I don't think we
> > >>> should use that time slot for swap alignment.
> > >>>
> > >>> We should find a time slot more friendly to Asia.
> > >>
> > >> Any time slot would have that kind of problem. We're spread out across
> > >> the globe.
> > >>
> > >> Let's just use a standardized time slot we have for MM alignment sessions.
> > >
> > > There are more swap maintainers in Asia than in the US + Europe, at
> > > least based on the maintainer file. Please be more inclusive. If the
> > > alignment is done without key stakeholders, it miss the point.
> > >
> > > Sigh, we can't even align on a time slot.
> > >
> > > In that case, let's keep discussing on the mailing list. At least it
> > > is accessible to every one.
> >
> > Looking at the mailing list, that approach doesn't seem to work.
> >
> > Finding a time slot that makes US, Europe and Asia happy is ... tricky.
> >
> > 1 AM is certainly unpleasant.
> >
> > US vs. Asia is also tricky, but doable.
> >
> > China 8AM vs. US West Coast 5PM?
> >
> > China 9AM vs. US West Coast 6PM?
>
> Hi David,
>
> Thanks for organizing this. Time slot that works for Baoquan and
> Kairui should also work for me.

Let's see Baoquan and other's suggestion, both slot are fine to me as well.

>
> Hi Kairui,
>
> I understand that you have some face-to-face discussions at the
> conference. Do we have a list of what has been aligned and what is
> pending to discuss? We should have an agenda to avoid repeating
> already aligned items.

Right, from my perspective, here are the following key points we can
discuss further in the incoming meeting (most of them are not fully
concluded yet):

1. A limitation for the logical size: from my side, there are real
usages for a global non-memcg limitation of the non-physical swap
space: e.g. thin VMs as containers/pods with no cgroup limitations
inside but which need in-VM memory compression and a proper limitation
to avoid thrashing; or low-end devices/desktops that want global
(root) limitations. And also, Android have a limitation on the ZRAM
size (well for this one I'm not from Android team though so that's
just my personal development experience with Android, enlarging the
ZRAM size on several Phone swill cause serious junky of Apps due to
over compression).

Nhat is concerned that exposing the sizing allows users to tune it and
potentially misconfigure the system. However, I think a user with root
permission should be fully aware of what they are doing or they can
easily mess up the system in many ways and swap limitation is a very
minor concern to me.

I think the requirement for a logical non-cgroup limitation is strong,
but the discussion hasn't concluded on the implementation method.
Perhaps something like a Kconfig combined with an interface or command
line? More ideas are welcome.

2. Charging: If you consider memory.swap is physical only then indeed
we should not charge it, however, user are already doing that for
years so this is a behavior change and we are also pushing memsw into
memcgv2 as a interface to limit the logical memory usage of a
container. So charging of the logical space is useful, how to handle
that is tricky though.

>From our usage, this should at least not block adding memsw or
anything similar for memcgv2, even if you want more customized cgroup
accounting, we need to charge it into some counter (a page counter,
not just a statistic) in some way.

3. Swapoff: This was discussed again too, as vswap was trying to
remove it. I think the concern is mostly about maintenance,
performance, and practicality. From my perspective it's a critical
component both for preventing minor or major faults before predictable
high traffic arrives, or for operations/debugging, and for releasing
the swap metadata to rule out any potential swap / page fault effect.
There are concerns about maintenance or suggestions to use MADV, while
I'll be happy to explore and improve the current in-kernel
implementation of swapoff later if needed but removing it is a really
bad idea in my view.

4. Writeback: No doubt we all agree that we definitely should have
writeback support, Nhat's concern is that we should handle the case
where some cgroup doesn't need zswap/compression and ensure that works
well.

5. Interface: Given the issues above, what should the interface look
like (swapfile, sysfs, /proc, etc.) and how should multiple
(non-physical) swapfiles be used? Nothing much is discussed about this
part though. I've heard users mention the use case of multiple
compression swap spaces, but I don't have a use case for that myself,
so I don't have many comments.

6. The one part that I think we can and should agree on it shat the
implement approach: at this point I think VM_SPARSE is the right
direction, Nhat is concerned about the testing on it, and I think we
can have more data for that, and collabration is highly encouraged. I
previously conducted many tests on everything posted from both sides,
will try to post more on this too.

That's a lot of problems already. I think we can discuss these points
further in the meeting.