Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210127233345.339910-1-shy828301@gmail.com> <20210127233345.339910-5-shy828301@gmail.com>
 <255b9236-3e0b-f6f6-4a72-5e69351a979a@suse.cz> <CAHbLzkrN2aW03TUrC3sOANS7YV6+KMisDtsXDH2W42-1tOJziw@mail.gmail.com>
 <b2f23595-e89c-b125-846e-d8b8dd362a04@suse.cz>
In-Reply-To: <b2f23595-e89c-b125-846e-d8b8dd362a04@suse.cz>
From:   Yang Shi <shy828301@gmail.com>
Date:   Fri, 29 Jan 2021 09:05:30 -0800
Message-ID: <CAHbLzkruSYh8DCBsaDOys0s-hkyi07PAAe1gdKOfGjEh08do4g@mail.gmail.com>
Subject: Re: [v5 PATCH 04/11] mm: vmscan: remove memcg_shrinker_map_size
To:     Vlastimil Babka <vbabka@suse.cz>
Cc:     Roman Gushchin <guro@fb.com>, Kirill Tkhai <ktkhai@virtuozzo.com>,
        Shakeel Butt <shakeelb@google.com>,
        Dave Chinner <david@fromorbit.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux MM <linux-mm@kvack.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jan 29, 2021 at 3:22 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 1/28/21 10:22 PM, Yang Shi wrote:
> >> > @@ -266,12 +265,13 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg)
> >> >  static int expand_shrinker_maps(int new_id)
> >> >  {
> >> >       int size, old_size, ret = 0;
> >> > +     int new_nr_max = new_id + 1;
> >> >       struct mem_cgroup *memcg;
> >> >
> >> > -     size = DIV_ROUND_UP(new_id + 1, BITS_PER_LONG) * sizeof(unsigned long);
> >> > -     old_size = memcg_shrinker_map_size;
> >> > +     size = (new_nr_max / BITS_PER_LONG + 1) * sizeof(unsigned long);
> >> > +     old_size = (shrinker_nr_max / BITS_PER_LONG + 1) * sizeof(unsigned long);
> >>
> >> What's wrong with using DIV_ROUND_UP() here?
> >
> > I don't think there is anything wrong with DIV_ROUND_UP. Should be
> > just different taste and result in shorter statement.
>
> IMHO it's not just taste. DIV_ROUND_UP() says what it does and you don't need to
> guess it from the math expression. Also your expression is shorter as it simply
> adds + 1, so if shrinker_nr_max is a multiple of BITS_PER_LONG, there's an extra
> unsigned long that shouldn't be needed. People reading that code will wonder
> whether there was some non-obvious intention behind that, and possibly send
> cleanup patches.

OK, will replace back to DIV_ROUND_UP(). And, a helper macro is
introduced in patch #6, will add that helper in this patch and use
DIV_ROUND_UP() in the helper.

>
> >>
> >> >       if (size <= old_size)
> >> > -             return 0;
> >> > +             goto out;
> >>
> >> Can this even happen? Seems to me it can't, so just remove this?
> >
> > Yes, it can. The maps use unsigned long value for bitmap, so any
> > shrinker ID < 31 would fall into the same unsigned long, so we may see
> > size <= old_size, but we need increase shrinker_nr_max since
> > expand_shrinker_maps() is called iff id >= shrinker_nr_max.
>
> Ah, good point.