Re: [PATCH v3 00/14] mm, swap: extendable swap devices (xswap)

[David Hildenbrand (Arm)]

On 9/17/26 15:17, Johannes Weiner wrote:
> On Thu, Sep 17, 2026 at 03:31:23PM +0800, Baoquan He wrote:
>> On 09/16/26 at 12:45pm, Johannes Weiner wrote:
>>>
>>> If the swap maintainers prefer the VM_SPARSE route, I'm happy to defer
>>> to them on that.
>>>
>>> However, from the cgroup and zswap camp, two stipulations that I
>>> reasoned out in the other thread[1]:
>>
>>>
>>> 1. You must not charge compression space as swap space to the cgroup.
>>
>> Hmm, I don't have a stance on this. However, isn't this an issue
>> zswap/zram have been doing? It feels like an independent issue which
>> should be done separately?
> 
> If you have 3 containers using compression space, and two of them have
> writeback enabled to a shared swapfile, the memory.swap.* controls
> need to work to manage fair access to that swapfile. They do not work
> if compression space itself is conflated in.
> 
> Right now zswap entries actually consume physical swapfile space, even
> before writeback. Charging the space is correct. But the whole point
> is to decouple compression space from physical swap space.
> 
> This is not something that can be done later. It would be a dramatic
> user-visible change to how the resource is categorized and managed.
> 
>>> 2. You must make the compression space large enough to be outside the
>>>    range where users can hit space limits before hitting memory limits.
>>
>> We may need a way to define 'large enough' at first.
> 
> I've tried to lay this out in the other thread, and highlighted the
> usability issues that result from hitting compression space limits
> prematurely. It's kind of your call whether you want to seriously
> engage with this or not.
> 
> But ultimately it's your claim that a static size can be made to work,
> so it's on you to make a convincing case.
> 
>>>    That also means not allowing setups where this is possible.
>>
>> And the limit is only an optional knob. If the admin does not set it,
>> the device grows to the full address space, so there is no space limit
>> to hit at all. It already behaves the way you want by default. The knob
>> is only for admins who want a ceiling, they can use it or not. I hope
>> this would not be a problem for your use case.                                                  
> 
> No, I've laid this out already as well.
> 
> This isn't about "my" usecase. It's about designing a coherent
> interface that works well with a large number of usecases, and other
> pieces of kernel infrastructure commonly used in conjunction.

Johannes, I read this as a NAK for now to the current approach from the memcg
side, is that correct?

I've tried to follow the discussion on the other thread, but it just exploded
and some of the things I read there made me rather upset late on a Friday evening.

-- 
Cheers,

David