All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Chen Ridong <chenridong@huaweicloud.com>
Cc: Yosry Ahmed <yosryahmed@google.com>,
	akpm@linux-foundation.org, mhocko@kernel.org,
	roman.gushchin@linux.dev, shakeel.butt@linux.dev,
	muchun.song@linux.dev, davidf@vimeo.com, vbabka@suse.cz,
	mkoutny@suse.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	chenridong@huawei.com, wangweiyang2@huawei.com
Subject: Re: [PATCH v3 next 4/5] memcg: factor out stat(event)/stat_local(event_local) reading functions
Date: Thu, 23 Jan 2025 23:23:02 -0500	[thread overview]
Message-ID: <20250124042302.GA5581@cmpxchg.org> (raw)
In-Reply-To: <6daaf853-1283-42e6-bb0f-55d951edc925@huaweicloud.com>

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@cmpxchg.org> wrote:
> >>>
> >>> On Fri, Jan 17, 2025 at 01:46:44AM +0000, Chen Ridong wrote:
> >>>> From: Chen Ridong <chenridong@huawei.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@huawei.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.

  reply	other threads:[~2025-01-24  4:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-17  1:46 [PATCH v3 next 0/5] Some cleanup for memcg Chen Ridong
2025-01-17  1:46 ` [PATCH v3 next 1/5] memcg: use OFP_PEAK_UNSET instead of -1 Chen Ridong
2025-01-17 16:47   ` Johannes Weiner
2025-01-17  1:46 ` [PATCH v3 next 2/5] memcg: call the free function when allocation of pn fails Chen Ridong
2025-01-17 16:47   ` Johannes Weiner
2025-01-17  1:46 ` [PATCH v3 next 3/5] memcg: factor out the replace_stock_objcg function Chen Ridong
2025-01-17 16:48   ` Johannes Weiner
2025-01-17  1:46 ` [PATCH v3 next 4/5] memcg: factor out stat(event)/stat_local(event_local) reading functions Chen Ridong
2025-01-17 16:56   ` Johannes Weiner
2025-01-17 17:01     ` Yosry Ahmed
2025-01-17 18:02       ` Johannes Weiner
2025-01-21 14:15         ` Chen Ridong
2025-01-24  4:23           ` Johannes Weiner [this message]
2025-01-24  7:42             ` Chen Ridong
2025-01-17  1:46 ` [PATCH v3 next 5/5] memcg: move the 'local' functions to memcontrol-v1.c Chen Ridong
2025-01-17 16:57   ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250124042302.GA5581@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=chenridong@huawei.com \
    --cc=chenridong@huaweicloud.com \
    --cc=davidf@vimeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=vbabka@suse.cz \
    --cc=wangweiyang2@huawei.com \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.