linux-kernel - Re: [PATCH] mm: memcontrol: move memsw charge callbacks to v1

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: <ai7tz7posbzx4jgleqitnf2bs7gdiqgve3jgvfwb6vycmml34h@nzzhd2sjag4a>
Date: Sun, 26 Jan 2025 22:31:04 -0800
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Johannes Weiner <hannes@...xchg.org>, Kairui Song <kasong@...cent.com>, 
	Chris Li <chrisl@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	Michal Hocko <mhocko@...e.com>, Roman Gushchin <roman.gushchin@...ux.dev>, 
	Muchun Song <muchun.song@...ux.dev>, linux-mm@...ck.org, cgroups@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: memcontrol: move memsw charge callbacks to v1

On Fri, Jan 24, 2025 at 12:41:32AM -0500, Johannes Weiner wrote:
> The interweaving of two entirely different swap accounting strategies
> has been one of the more confusing parts of the memcg code. Split out
> the v1 code to clarify the implementation and a handful of callsites,
> and to avoid building the v1 bits when !CONFIG_MEMCG_V1.
> 
>    text	  data	   bss	   dec	   hex	filename
>   39253	  6446	  4160	 49859	  c2c3	mm/memcontrol.o.old
>   38877	  6382	  4160	 49419	  c10b	mm/memcontrol.o
> 
> Signed-off-by: Johannes Weiner <hannes@...xchg.org>

Thanks Johannes for the patch as it is related to the topic which I
think we need to make a decision on i.e. v1's swap accounting semantics
in v2. I know Google and Tencent [1] are still very deeply dependent on
v1's swap accounting semantics.

Folks from Google and Tencent, if this topic is still relevant for you,
can you please propose a LSFMM topic for this (or any other forum where
we can reach a decision).

[1] https://lore.kernel.org/all/CAMgjq7ARr0=OG8GQOJvzLtfdrtiwvJ19-mx1snxqmLE0Za+QCw@mail.gmail.com/