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] [day] [month] [year] [list]
Message-ID: <a90b33c3-7ea3-5375-3fcd-c97cc13c9964@google.com>
Date: Thu, 23 Jan 2025 22:53:04 -0800 (PST)
From: Hugh Dickins <hughd@...gle.com>
To: Johannes Weiner <hannes@...xchg.org>
cc: Andrew Morton <akpm@...ux-foundation.org>, Michal Hocko <mhocko@...e.com>, 
    Roman Gushchin <roman.gushchin@...ux.dev>, 
    Shakeel Butt <shakeel.butt@...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, 24 Jan 2025, 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>

I'm not really looking at this, but want to chime in that I found the
memcg1 swap stuff in mm/memcontrol.c, not in mm/memcontrol-v1.c, very
misleading when I was doing the folio_unqueue_deferred_split() business:
so, without looking into the details of it, strongly approve of the
direction you're taking here - thank you.

But thought you could go even further, given that
static inline bool do_memsw_account(void)
{
	return !cgroup_subsys_on_dfl(memory_cgrp_subsys);
}

I thought that amounted to do_memsw_account iff memcg_v1;
but I never did grasp cgroup_subsys_on_dfl very well,
so ignore me if I'm making no sense to you.

Hugh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ