linux-kernel - Re: [RFC 0/5] add option to restore swap account to cgroupv1 mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <gkuatggv6jhbl32x7rpzlcifcno6hoirw43v35vtkfflqmepfw@wwyz7x6hc4id>
Date: Wed, 19 Mar 2025 12:27:19 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Jingxiang Zeng <linuszeng@...cent.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org, cgroups@...r.kernel.org, 
	linux-kernel@...r.kernel.org, hannes@...xchg.org, mhocko@...nel.org, roman.gushchin@...ux.dev, 
	muchun.song@...ux.dev, kasong@...cent.com, Tejun Heo <tj@...nel.org>
Subject: Re: [RFC 0/5] add option to restore swap account to cgroupv1 mode

+Tejun

Hi Zeng,

On Wed, Mar 19, 2025 at 02:41:43PM +0800, Jingxiang Zeng wrote:
> From: Zeng Jingxiang <linuszeng@...cent.com>
> 
> 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.
> 
> As discussed in [1], this patch set can change the semantics of
> of memory.swap.max/current to the v1-like behavior.
> 
> Link:
> https://lore.kernel.org/all/Zk-fQtFrj-2YDJOo@P9FQF9L96D.corp.robot.car/ [1]

Overall I don't have objection but I would like to keep the changes
separate from v2 code as much as possible.

More specifically:

1. Keep CONFIG_MEMSW_ACCOUNT_ON_DFL dependent on CONFIG_MEMCG_V1 and
   disabled by default (as you already did).

2. Keep the changes in memcontrol-v1.[h|c] as much as possible.

I will go over the patches but let's see what others have to say.