All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>,
	David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>,
	Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v1] mm/memory_hotplug: Easier calculation to get pages to next section boundary
Date: Thu, 6 Feb 2020 12:39:24 +0800	[thread overview]
Message-ID: <20200206043924.GM8965@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20200206043401.22i2cucwqctsrtps@master>

On 02/06/20 at 04:34am, Wei Yang wrote:
> On Thu, Feb 06, 2020 at 10:48:16AM +0800, Baoquan He wrote:
> >On 02/06/20 at 02:26am, Wei Yang wrote:
> >> On Thu, Feb 06, 2020 at 08:37:36AM +0800, Baoquan He wrote:
> >> >On 02/06/20 at 08:13am, Baoquan He wrote:
> >> >> On 02/06/20 at 07:50am, Wei Yang wrote:
> >> >> > On Thu, Feb 06, 2020 at 07:19:45AM +0800, Wei Yang wrote:
> >> >> > >On Wed, Feb 05, 2020 at 02:52:51PM +0100, David Hildenbrand wrote:
> >> >> > >>Let's use a calculation that's easier to understand and calculates the
> >> >> > >>same result. Reusing existing macros makes this look nicer.
> >> >> > >>
> >> >> > >>We always want to have the number of pages (> 0) to the next section
> >> >> > >>boundary, starting from the current pfn.
> >> >> > >>
> >> >> > >>Suggested-by: Segher Boessenkool <segher@kernel.crashing.org>
> >> >> > >>Cc: Andrew Morton <akpm@linux-foundation.org>
> >> >> > >>Cc: Michal Hocko <mhocko@kernel.org>
> >> >> > >>Cc: Oscar Salvador <osalvador@suse.de>
> >> >> > >>Cc: Baoquan He <bhe@redhat.com>
> >> >> > >>Cc: Wei Yang <richardw.yang@linux.intel.com>
> >> >> > >>Signed-off-by: David Hildenbrand <david@redhat.com>
> >> >> > >
> >> >> > >Reviewed-by: Wei Yang <richardw.yang@linux.intel.com>
> >> >> > >
> >> >> > >BTW, I got one question about hotplug size requirement.
> >> >> > >
> >> >> > >I thought the hotplug range should be section size aligned, while taking a
> >> >> > >look into current code function check_hotplug_memory_range() guard the range.
> >> >> 
> >> >> A good question. The current code should be block size aligned. I
> >> >> remember in some places we assume each block comprise all the sections.
> >> >> Can't imagine one or some of them are half section filled.
> >> >
> >> >I could be wrong, half filled block may not cause problem. 
> >> >
> >> 
> >> David must be angry about our flooding the mail list :-)
> >
> >Believe he won't, :-) If you like, we can talk off line.
> >
> >> 
> >> Check the code again, there are two memory range check:
> >> 
> >>   * check_hotplug_memory_range(), block/section aligned
> >>   * check_pfn_span(), subsection aligned
> >> 
> >> The second check, check_pfn_span() in __add_pages(), enable the capability to
> >> add a memory range with subsection size.
> >> 
> >> This means hotplug still keeps section alignment.
> >
> >memremap_pages() also call add_pages(), it doesn't have the
> >check_hotplug_memory_range() invocation. check_pfn_span() is made for
> >it specifically.
> >
> 
> If my understanding is correct, memremap_pages() is used to add some dev
> memory to system. This is the use case which Dan want to enable for
> sub-section. Since memremap_pages() is not called in mem-hotplug path, this
> doesn't affect the hotplug range alignment.

Yeah, we are on the same page.

> 
> >> 
> >> BTW, __add_pages() share the same logic as __remove_pages(). Why not change it
> >> too? Do I miss something or I don't have the latest source code?
> >
> >Good question, and I think it need. Just David is refactoring/cleaning
> >up the remove_pages() code path, this is found out by Segher from patch
> >reviewing.
> 
> Ah, we may need a following cleanup :-)

Agree. See what David will say. Fold it into this patch, or anyone post
a new one.



  reply	other threads:[~2020-02-06  4:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 13:52 [PATCH v1] mm/memory_hotplug: Easier calculation to get pages to next section boundary David Hildenbrand
2020-02-05 23:19 ` Wei Yang
2020-02-05 23:50   ` Wei Yang
2020-02-06  0:13     ` Baoquan He
2020-02-06  0:37       ` Baoquan He
2020-02-06  2:26         ` Wei Yang
2020-02-06  2:48           ` Baoquan He
2020-02-06  4:34             ` Wei Yang
2020-02-06  4:39               ` Baoquan He [this message]
2020-02-06  9:01                 ` David Hildenbrand
2020-02-06 11:38                   ` Wei Yang
2020-02-06  1:46 ` 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=20200206043924.GM8965@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=richard.weiyang@gmail.com \
    --cc=richardw.yang@linux.intel.com \
    --cc=segher@kernel.crashing.org \
    /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.