linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Wei Yang <richard.weiyang@gmail.com>,
	mhocko@suse.com, linux-mm@kvack.org
Subject: Re: [RFC PATCH 2/4] mm/hotplug: walk_memroy_range on memory_block uit
Date: Mon, 26 Jun 2017 00:32:40 -0700	[thread overview]
Message-ID: <eeb06db0-086a-29f9-306d-a702984594df@nvidia.com> (raw)
In-Reply-To: <20170625025227.45665-3-richard.weiyang@gmail.com>

On 06/24/2017 07:52 PM, Wei Yang wrote:
> hotplug memory range is memory_block aligned and walk_memroy_range guarded
> with check_hotplug_memory_range(). This is save to iterate on the
> memory_block base.> 
> This patch adjust the iteration unit and assume there is not hole in
> hotplug memory range.

Hi Wei,

In the patch subject, s/memroy/memory/ , and s/uit/unit/, and
s/save/safe.

Actually, I still have a tough time with it, so maybe the 
description above could instead be worded approximately
like this:

Given that a hotpluggable memory range is now block-aligned,
it is safe for walk_memory_range to iterate by blocks.

Change walk_memory_range() so that it iterates at block
boundaries, rather than section boundaries. Also, skip the check
for whether pages are present in the section, and assume 
that there are no holes in the range. (<Insert reason why 
that is safe, here>)


> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> ---
>  mm/memory_hotplug.c | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index f5d06afc8645..a79a83ec965f 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1858,17 +1858,11 @@ int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
>  	unsigned long pfn, section_nr;
>  	int ret;
>  
> -	for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> +	for (pfn = start_pfn; pfn < end_pfn;
> +		pfn += PAGES_PER_SECTION * sections_per_block) {

Here, and in one or two other spots in the patch, it would be nice
to repeat your approach from patch 0001, where you introduced a
pages_per_block variable. That definitely helps when reading the code.

>  		section_nr = pfn_to_section_nr(pfn);
> -		if (!present_section_nr(section_nr))
> -			continue;

Why is it safe to assume no holes in the memory range? (Maybe Michal's 
patch already covered this and I haven't got that far yet?)

The documentation for this routine says that it walks through all
present memory sections in the range, so it seems like this patch
breaks that.

>  
>  		section = __nr_to_section(section_nr);
> -		/* same memblock? */
> -		if (mem)
> -			if ((section_nr >= mem->start_section_nr) &&
> -			    (section_nr <= mem->end_section_nr))
> -				continue;

Yes, that deletion looks good.

thanks,
john h

>  
>  		mem = find_memory_block_hinted(section, mem);
>  		if (!mem)
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-06-26  7:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-25  2:52 [RFC PATCH 0/4] mm/hotplug: make hotplug memory_block alligned Wei Yang
2017-06-25  2:52 ` [RFC PATCH 1/4] mm/hotplug: aligne the hotplugable range with memory_block Wei Yang
2017-06-25  3:31   ` John Hubbard
2017-06-26  0:20     ` Wei Yang
2017-06-26  6:49       ` John Hubbard
2017-06-26 23:21         ` Wei Yang
2017-06-25  2:52 ` [RFC PATCH 2/4] mm/hotplug: walk_memroy_range on memory_block uit Wei Yang
2017-06-26  7:32   ` John Hubbard [this message]
2017-06-26 23:40     ` Wei Yang
2017-06-27  6:59       ` John Hubbard
2017-06-28  0:11         ` Wei Yang
2017-06-25  2:52 ` [RFC PATCH 3/4] mm/hotplug: make __add_pages() iterate on memory_block and split __add_section() Wei Yang
2017-06-26  7:50   ` John Hubbard
2017-06-26 23:53     ` Wei Yang
2017-06-27  6:47       ` John Hubbard
2017-06-28  0:16         ` Wei Yang
2017-06-28  0:22   ` Wei Yang
2017-06-25  2:52 ` [RFC PATCH 4/4] base/memory: pass start_section_nr to init_memory_block() Wei Yang
2017-06-27  7:11   ` John Hubbard
2017-06-28  0:18     ` Wei Yang
2017-06-26  7:46 ` [RFC PATCH 0/4] mm/hotplug: make hotplug memory_block alligned Michal Hocko
2017-06-27  2:13   ` Wei Yang
2017-06-28  9:43     ` Michal Hocko

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=eeb06db0-086a-29f9-306d-a702984594df@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=richard.weiyang@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).