On 2025/1/24 12:23, Johannes Weiner wrote: > 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@xxxxxxxxxxx> wrote: >>>>> >>>>> On Fri, Jan 17, 2025 at 01:46:44AM +0000, Chen Ridong wrote: >>>>>> From: Chen Ridong <chenridong@xxxxxxxxxx> >>>>>> >>>>>> 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@xxxxxxxxxx> >>>>> >>>>> 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. Thank you, will do that. Best regards, Ridong
