linux-kernel - Re: [PATCH v3 next 4/5] memcg: factor out stat(event)/stat_local(event

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: <20250124042302.GA5581@cmpxchg.org>
Date: Thu, 23 Jan 2025 23:23:02 -0500
From: Johannes Weiner <hannes@...xchg.org>
To: Chen Ridong <chenridong@...weicloud.com>
Cc: Yosry Ahmed <yosryahmed@...gle.com>, akpm@...ux-foundation.org,
	mhocko@...nel.org, roman.gushchin@...ux.dev, shakeel.butt@...ux.dev,
	muchun.song@...ux.dev, davidf@...eo.com, vbabka@...e.cz,
	mkoutny@...e.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	cgroups@...r.kernel.org, chenridong@...wei.com,
	wangweiyang2@...wei.com
Subject: Re: [PATCH v3 next 4/5] memcg: factor out
 stat(event)/stat_local(event_local) reading functions

On Tue, Jan 21, 2025 at 10:15:00PM +0800, Chen Ridong wrote:
> 
> 
> On 2025/1/18 2:02, Johannes Weiner wrote:
> > On Fri, Jan 17, 2025 at 09:01:59AM -0800, Yosry Ahmed wrote:
> >> On Fri, Jan 17, 2025 at 8:56 AM Johannes Weiner <hannes@...xchg.org> wrote:
> >>>
> >>> On Fri, Jan 17, 2025 at 01:46:44AM +0000, Chen Ridong wrote:
> >>>> From: Chen Ridong <chenridong@...wei.com>
> >>>>
> >>>> The only difference between 'lruvec_page_state' and
> >>>> 'lruvec_page_state_local' is that they read 'state' and 'state_local',
> >>>> respectively. Factor out an inner functions to make the code more concise.
> >>>> Do the same for reading 'memcg_page_stat' and 'memcg_events'.
> >>>>
> >>>> Signed-off-by: Chen Ridong <chenridong@...wei.com>
> >>>
> >>> bool parameters make for poor readability at the callsites :(
> >>>
> >>> With the next patch moving most of the duplication to memcontrol-v1.c,
> >>> I think it's probably not worth refactoring this.
> >>
> >> Arguably the duplication would now be across two different files,
> >> making it more difficult to notice and keep the implementations in
> >> sync.
> > 
> > Dependencies between the files is a bigger pain. E.g. try_charge()
> > being defined in memcontrol-v1.h makes memcontrol.c more difficult to
> > work with. That shared state also immediately bitrotted when charge
> > moving was removed and the last cgroup1 caller disappeared.
> > 
> > The whole point of the cgroup1 split was to simplify cgroup2 code. The
> > tiny amount of duplication in this case doesn't warrant further
> > entanglement between the codebases.
> 
> Thank you for your review.
> 
> I agree with that. However, If I just move the 'local' functions to
> memcontrol-v1.c, I have to move some dependent declarations to the
> memcontrol-v1.h.
> E.g. struct memcg_vmstats, MEMCG_VMSTAT_SIZE and so on.
> 
> Is this worth doing?

Ah, right. No, that's not worth it.

The easiest way is to slap CONFIG_MEMCG_V1 guards around the local
functions but leave them in memcontrol.c for now. We already have a
few of those ifdefs for where splitting/sharing wasn't practical. At
least then it's clearly marked and they won't get built.