All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: 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 23:59:52 -0700	[thread overview]
Message-ID: <3ad226f5-92f1-352a-d7ee-159eef5d60e3@nvidia.com> (raw)
In-Reply-To: <20170626234038.GD53180@WeideMacBook-Pro.local>

On 06/26/2017 04:40 PM, Wei Yang wrote:
> On Mon, Jun 26, 2017 at 12:32:40AM -0700, John Hubbard wrote:
>> On 06/24/2017 07:52 PM, Wei Yang wrote:
[...]
>>
>> 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.

OK. In that case, it seems like we should update the function documentation
to match. Something like this, maybe? :

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index bdaafcf46f49..d36b2f4eaf39 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1872,14 +1872,14 @@ int offline_pages(unsigned long start_pfn, unsigned long nr_pages)
 #endif /* CONFIG_MEMORY_HOTREMOVE */
 
 /**
- * walk_memory_range - walks through all mem sections in [start_pfn, end_pfn)
+ * walk_memory_range - walks through all mem blocks in [start_pfn, end_pfn)
  * @start_pfn: start pfn of the memory range
  * @end_pfn: end pfn of the memory range
  * @arg: argument passed to func
- * @func: callback for each memory section walked
+ * @func: callback for each memory block walked
  *
- * This function walks through all present mem sections in range
- * [start_pfn, end_pfn) and call func on each mem section.
+ * This function walks through all mem blocks in the range
+ * [start_pfn, end_pfn) and calls func on each mem block.
  *
  * Returns the return value of func.
  */


thanks,
john h

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

--
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-27  6:59 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
2017-06-27  6:59       ` John Hubbard [this message]
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=3ad226f5-92f1-352a-d7ee-159eef5d60e3@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 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.