Re: Path forward for Virtualized Swap?

[David Hildenbrand (Arm)]

On 10/14/26 19:17, Kairui Song wrote:
> 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:
>>>
>>>
>>> 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.

Just in general, if I'm attending and it's 2/3am in the night, I would
appreciate a short summary of "these things were already sorted out". I might
have some weird swap-related dreams afterwards, but it would certainly help
keeping my brain awake.

Surprisingly, sometimes summarizing common understandings still sparks
discussions ;)

-- 
Cheers,

David