Re: [PATCH v3 1/4] mm, memcontrol: avoid duplicated memcg enable check

["Huang, Ying" <ying.huang@linux.alibaba.com>]

Kairui Song <ryncsn@gmail.com> writes:

> On Sun, Dec 22, 2024 at 9:33 PM Huang, Ying
> <ying.huang@linux.alibaba.com> wrote:
>>
>> Hi, Kairui,
>
> Hi Ying,
>
>>
>> Sorry for jumping in so late.
>>
>> Kairui Song <ryncsn@gmail.com> writes:
>>
>> > From: Kairui Song <kasong@tencent.com>
>> >
>> > mem_cgroup_uncharge_swap() includes a mem_cgroup_disabled() check,
>> > so the caller doesn't need to check that.
>> >
>> > Signed-off-by: Kairui Song <kasong@tencent.com>
>> > Reviewed-by: Yosry Ahmed <yosryahmed@google.com>
>> > Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev>
>> > Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
>> > Acked-by: Chris Li <chrisl@kernel.org>
>> > ---
>> >  mm/memcontrol.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> > index 7b3503d12aaf..79900a486ed1 100644
>> > --- a/mm/memcontrol.c
>> > +++ b/mm/memcontrol.c
>> > @@ -4609,7 +4609,7 @@ void mem_cgroup_swapin_uncharge_swap(swp_entry_t entry, unsigned int nr_pages)
>> >        * correspond 1:1 to page and swap slot lifetimes: we charge the
>> >        * page to memory here, and uncharge swap when the slot is freed.
>> >        */
>> > -     if (!mem_cgroup_disabled() && do_memsw_account()) {
>> > +     if (do_memsw_account()) {
>> >               /*
>> >                * The swap entry might not get freed for a long time,
>> >                * let's not wait for it.  The page already received a
>>
>> I take a look at memcontrol.c, it appears that almost all extern
>> functions check mem_cgroup_disabled() as the first step.
>
> Hmm, just checked memcontrol.c and I saw quite a few extern functions
> not doing that, so I think that's not a convention.

I still think that it's a good idea to check whether memcg is disabled
in the outermost interfaces instead of being buried in some internal
functions.

>> that this is a convention of memcontrol.c?  And the benefit of the
>> change is minimal.  In contrast, if someone makes more changes to
>> mem_cgroup_swapin_uncharge_swap() in the future, he may forget to add
>> this back.  So, it may be unnecessary to make the change?
>
> This change is minimal indeed, it only helps to remove a few unneeded
> nop, still a gain though.

The benefit is minimal too.

> I think mem_cgroup_swapin_uncharge_swap should fade away in the future,

Good.  Then, we don't need to optimize it too.  Just let it fade away.

> it's only for Cgroup V1, and it's a really simple function, just a
> wrapper for mem_cgroup_uncharge_swap, so I think this is not a
> problem?
>
> If you are concerned about this, this patch can be dropped from this
> series, rest of the patches still work the same.

Just my 2 cents.

---
Best Regards,
Huang, Ying