From: Matthew Wilcox <willy@infradead.org>
To: Chris Down <chris@chrisdown.name>
Cc: qiwuchen55@gmail.com, akpm@linux-foundation.org,
linux-mm@kvack.org, chenqiwu <chenqiwu@xiaomi.com>
Subject: Re: [PATCH] mm/vmscan: fix incorrect return type for cgroup_reclaim()
Date: Thu, 19 Mar 2020 10:36:06 -0700 [thread overview]
Message-ID: <20200319173606.GL22433@bombadil.infradead.org> (raw)
In-Reply-To: <20200319162025.GA237751@chrisdown.name>
On Thu, Mar 19, 2020 at 04:20:25PM +0000, Chris Down wrote:
> qiwuchen55@gmail.com writes:
> > From: chenqiwu <chenqiwu@xiaomi.com>
> >
> > The return type of cgroup_reclaim() is bool, but the correct type
> > should be struct mem_cgroup pointer. As a result, cgroup_reclaim()
> > can be used to wrap sc->target_mem_cgroup in vmscan code.
>
> The code changes looks okay to me, but the changelog and patch subject could
> do with some improvement. For example, the type isn't "incorrect" before and
> "correct" now, per se, it's just coercing from *struct mem_cgroup to bool.
>
> Could you make it more clear what your intent is in the patch? If it's that
> you found the code confusing, you can just write something like:
>
> mm/vmscan: return target_mem_cgroup from cgroup_reclaim
>
> Previously the code splits apart the action of checking whether we are
> in cgroup reclaim from getting the target memory cgroup for that
> reclaim. This split is confusing and seems unnecessary, since
> cgroup_reclaim itself only checks if sc->target_mem_cgroup is NULL or
> not, so merge the two use cases into one by returning the
> target_mem_cgroup itself from cgroup_reclaim.
Thank you for this better changelog; I have a better idea about what
this patch is doing now.
> > @@ -276,9 +276,9 @@ static void unregister_memcg_shrinker(struct shrinker *shrinker)
> > {
> > }
> >
> > -static bool cgroup_reclaim(struct scan_control *sc)
> > +static struct mem_cgroup *cgroup_reclaim(struct scan_control *sc)
> > {
> > - return false;
> > + return NULL;
> > }
I think this is actually the important bit. For those who build
their kernels with cgroups disabled, it will save a small number of
instructions since cgroup_reclaim() will be NULL rather than dereferencing
sc->target_mem_group. It'd be nice to have that saving quantified as
part of the changelog.
> > @@ -2625,7 +2626,7 @@ static inline bool should_continue_reclaim(struct pglist_data *pgdat,
> >
> > static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
> > {
> > - struct mem_cgroup *target_memcg = sc->target_mem_cgroup;
> > + struct mem_cgroup *target_memcg = cgroup_reclaim(sc);
It feels like the name is wrong, doesn't it? cgroup_reclaim() doesn't
really scream to me "I return a mem_cgroup pointer". I can't think of
a good name, but maybe someone else can.
next prev parent reply other threads:[~2020-03-19 17:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 15:50 [PATCH] mm/vmscan: fix incorrect return type for cgroup_reclaim() qiwuchen55
2020-03-19 16:07 ` Michal Hocko
2020-03-20 7:34 ` Baoquan He
2020-03-19 16:20 ` Chris Down
2020-03-19 17:36 ` Matthew Wilcox [this message]
2020-03-20 2:29 ` chenqiwu
2020-03-20 7:28 ` Michal Hocko
2020-03-20 2:20 ` chenqiwu
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=20200319173606.GL22433@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=chenqiwu@xiaomi.com \
--cc=chris@chrisdown.name \
--cc=linux-mm@kvack.org \
--cc=qiwuchen55@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).