All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: 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: Tue, 27 Jun 2017 07:40:38 +0800	[thread overview]
Message-ID: <20170626234038.GD53180@WeideMacBook-Pro.local> (raw)
In-Reply-To: <eeb06db0-086a-29f9-306d-a702984594df@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 3474 bytes --]

On Mon, Jun 26, 2017 at 12:32:40AM -0700, John Hubbard wrote:
>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.
>

Nice.

>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>)
>

Sounds better than mine :-)

>
>> 
>> 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.
>

Sounds nice, let me try to introduce the pages_per_block.

>>  		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.
>

Hmm... it is a little bit hard to describe.

First the documentation of the function is a little misleading. When you look
at the code, it call the "func" only once for a memory_block, not for every
present mem_section as it says. So have some memory in the memory_block would
meet the requirement.

Second, after the check in patch 1, it is for sure the range is memory_block
aligned, which means it must have some memory in that memory_block. It would
be strange if someone claim to add a memory range but with no real memory.

This is why I remove the check here.


>>  
>>  		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.
>

From this we can see, if there IS some memory, the function will be invoked
and only invoked once.

>thanks,
>john h
>
>>  
>>  		mem = find_memory_block_hinted(section, mem);
>>  		if (!mem)
>> 

-- 
Wei Yang
Help you, Help me

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2017-06-26 23:40 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
2017-06-26 23:40     ` Wei Yang [this message]
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=20170626234038.GD53180@WeideMacBook-Pro.local \
    --to=richard.weiyang@gmail.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.