From: Baoquan He <bhe@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, richardw.yang@linux.intel.com,
osalvador@suse.de, dan.j.williams@intel.com, rppt@linux.ibm.com,
robin.murphy@arm.com
Subject: Re: [PATCH v2 0/7] mm/hotplug: Only use subsection map in VMEMMAP case
Date: Wed, 26 Feb 2020 20:30:30 +0800 [thread overview]
Message-ID: <20200226123030.GG24216@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200226091421.GE3771@dhcp22.suse.cz>
On 02/26/20 at 10:14am, Michal Hocko wrote:
> On Wed 26-02-20 11:42:36, Baoquan He wrote:
> > On 02/25/20 at 11:02am, Michal Hocko wrote:
> > > On Tue 25-02-20 10:10:45, David Hildenbrand wrote:
> > > > >>> include/linux/mmzone.h | 2 +
> > > > >>> mm/sparse.c | 178 +++++++++++++++++++++++++++++------------
> > > > >>> 2 files changed, 127 insertions(+), 53 deletions(-)
> > > > >>
> > > > >> Why do we need to add so much code to remove a functionality from one
> > > > >> memory model?
> > > > >
> > > > > Hmm, Dan also asked this before.
> > > > >
> > > > > The adding mainly happens in patch 2, 3, 4, including the two newly
> > > > > added function defitions, the code comments above them, and those added
> > > > > dummy functions for !VMEMMAP.
> > > >
> > > > AFAIKS, it's mostly a bunch of newly added comments on top of functions.
> > > > E.g., the comment for fill_subsection_map() alone spans 12 LOC in total.
> > > > I do wonder if we have to be that verbose. We are barely that verbose on
> > > > MM code (and usually I don't see much benefit unless it's a function
> > > > with many users from many different places).
> > >
> > > I would tend to agree here. Not that I am against kernel doc
> > > documentation but these are internal functions and the comment doesn't
> > > really give any better insight IMHO. I would be much more inclined if
> > > this was the general pattern in the respective file but it just stands
> > > out.
> >
> > I saw there are internal functions which have code comments, e.g
> > shrink_slab() in mm/vmscan.c, not only this one place, there are several
> > places. I personally prefer to see code comment for function if
> > possible, this can save time, e.g people can skip the bitmap operation
> > when read code if not necessary. And here I mainly want to tell there
> > are different returned value to note different behaviour when call them.
>
> ... yet nobody really cares about different return code. It is an error
> that is propagated up the call chain and that's all.
>
> I also like when there is a kernel doc comment that helps to understand
> the intented usage, context the function can be called from, potential
> side effects, locking requirements and other details people need to know
Fair enough. As I have said, I didn't intend to stick to add kernel doc
comments for these two functions. Will remove them. Thanks for
reviewing.
> when calling functions. But have a look at
> /**
> * clear_subsection_map - Clear subsection map of one memory region
> *
> * @pfn - start pfn of the memory range
> * @nr_pages - number of pfns to add in the region
> *
> * This is only intended for hotplug, and clear the related subsection
> * map inside one section.
> *
> * Return:
> * * -EINVAL - Section already deactived.
> * * 0 - Subsection map is emptied.
> * * 1 - Subsection map is not empty.
> */
>
> the only useful information in here is that this is a hotplug stuff but
> I would be completely lost about the intention without already knowing
> what is this whole subsection about.
>
> --
> Michal Hocko
> SUSE Labs
>
next prev parent reply other threads:[~2020-02-26 12:30 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 4:33 [PATCH v2 0/7] mm/hotplug: Only use subsection map in VMEMMAP case Baoquan He
2020-02-20 4:33 ` [PATCH v2 1/7] mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case Baoquan He
2020-02-20 6:11 ` Wei Yang
2020-02-20 12:07 ` David Hildenbrand
2020-02-26 12:31 ` David Hildenbrand
2020-02-26 13:07 ` Baoquan He
2020-02-26 18:09 ` Dan Williams
2020-03-03 8:34 ` David Hildenbrand
2020-03-03 8:39 ` Baoquan He
2020-02-20 4:33 ` [PATCH v2 2/7] mm/sparse.c: introduce new function fill_subsection_map() Baoquan He
2020-02-20 6:14 ` Wei Yang
2020-02-28 14:27 ` David Hildenbrand
2020-03-01 4:59 ` Baoquan He
2020-02-20 4:33 ` [PATCH v2 3/7] mm/sparse.c: introduce a new function clear_subsection_map() Baoquan He
2020-02-20 6:15 ` Wei Yang
2020-02-28 14:36 ` David Hildenbrand
2020-03-01 5:20 ` Baoquan He
2020-03-02 15:43 ` David Hildenbrand
2020-03-03 1:53 ` Baoquan He
2020-03-03 8:22 ` Baoquan He
2020-03-03 8:33 ` David Hildenbrand
2020-03-03 8:38 ` Baoquan He
2020-02-20 4:33 ` [PATCH v2 4/7] mm/sparse.c: only use subsection map in VMEMMAP case Baoquan He
2020-02-20 6:17 ` Wei Yang
2020-02-25 9:57 ` Michal Hocko
2020-02-26 3:53 ` Baoquan He
2020-02-26 9:10 ` Michal Hocko
2020-02-28 7:25 ` Baoquan He
2020-02-20 4:33 ` [PATCH v2 5/7] mm/sparse.c: add code comment about sub-section hotplug Baoquan He
2020-02-20 4:33 ` [PATCH v2 6/7] mm/sparse.c: move subsection_map related codes together Baoquan He
2020-02-20 6:18 ` Wei Yang
2020-02-20 7:04 ` Baoquan He
2020-02-20 7:12 ` Wei Yang
2020-02-20 8:55 ` Baoquan He
2020-02-20 21:52 ` Wei Yang
2020-02-20 4:33 ` [PATCH v2 7/7] mm/sparse.c: Use __get_free_pages() instead in populate_section_memmap() Baoquan He
2020-02-20 10:38 ` [PATCH v2 0/7] mm/hotplug: Only use subsection map in VMEMMAP case Michal Hocko
2020-02-21 14:28 ` Baoquan He
2020-02-25 9:10 ` David Hildenbrand
2020-02-25 10:02 ` Michal Hocko
2020-02-26 3:42 ` Baoquan He
2020-02-26 9:14 ` Michal Hocko
2020-02-26 12:30 ` Baoquan He [this message]
2020-02-25 10:03 ` Michal Hocko
2020-02-26 3:44 ` Baoquan He
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=20200226123030.GG24216@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=osalvador@suse.de \
--cc=richardw.yang@linux.intel.com \
--cc=robin.murphy@arm.com \
--cc=rppt@linux.ibm.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).