On Wed, Mar 19, 2025 at 03:38:38PM -0400, Johannes Weiner wrote: > On Wed, Mar 19, 2025 at 02:41:43PM +0800, Jingxiang Zeng wrote: > > From: Zeng Jingxiang <linuszeng@xxxxxxxxxxx> > > > > memsw account is a very useful knob for container memory > > overcommitting: It's a great abstraction of the "expected total > > memory usage" of a container, so containers can't allocate too > > much memory using SWAP, but still be able to SWAP out. > > > > For a simple example, with memsw.limit == memory.limit, containers > > can't exceed their original memory limit, even with SWAP enabled, they > > get OOM killed as how they used to, but the host is now able to > > offload cold pages. > > > > Similar ability seems absent with V2: With memory.swap.max == 0, the > > host can't use SWAP to reclaim container memory at all. But with a > > value larger than that, containers are able to overuse memory, causing > > delayed OOM kill, thrashing, CPU/Memory usage ratio could be heavily > > out of balance, especially with compress SWAP backends. > > > > This patch set adds two interfaces to control the behavior of the > > memory.swap.max/current in cgroupv2: > > > > CONFIG_MEMSW_ACCOUNT_ON_DFL > > cgroup.memsw_account_on_dfl={0, 1} > > > > When one of the interfaces is enabled: memory.swap.current and > > memory.swap.max represents the usage/limit of swap. > > When neither is enabled (default behavior),memory.swap.current and > > memory.swap.max represents the usage/limit of memory+swap. > > This should be new knobs, e.g. memory.memsw.current, memory.memsw.max. > > Overloading the existing swap knobs is confusing. > > And there doesn't seem to be a good reason to make the behavior > either-or anyway. If memory.swap.max=max (default), it won't interfere > with the memsw operation. And it's at least conceivable somebody might > want to set both, memsw.max > swap.max, to get some flexibility while > excluding the craziest edge cases. At the moment memsw and swap shares the underlying page_counter. This would require having explicit page_counter for memsw. What's your take on memsw interfaces still behind CONFIG_MEMSW_ACCOUNT_ON_DFL?