Kairui Song <ryncsn@xxxxxxxxx> writes:
> On Sun, Dec 22, 2024 at 9:33 PM Huang, Ying
> <ying.huang@xxxxxxxxxxxxxxxxx> wrote:
>>
>> Hi, Kairui,
>
> Hi Ying,
>
>>
>> Sorry for jumping in so late.
>>
>> Kairui Song <ryncsn@xxxxxxxxx> writes:
>>
>> > From: Kairui Song <kasong@xxxxxxxxxxx>
>> >
>> > 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@xxxxxxxxxxx>
>> > Reviewed-by: Yosry Ahmed <yosryahmed@xxxxxxxxxx>
>> > Reviewed-by: Roman Gushchin <roman.gushchin@xxxxxxxxx>
>> > Acked-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>
>> > Acked-by: Chris Li <chrisl@xxxxxxxxxx>
>> > ---
>> > 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
