linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Xishi Qiu <qiuxishi@huawei.com>,
	zhong jiang <zhongjiang@huawei.com>,
	Joonsoo Kim <js1304@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] mm: unify new_node_page and alloc_migrate_target
Date: Thu, 8 Jun 2017 10:40:10 +0200	[thread overview]
Message-ID: <20170608084010.GB19866@dhcp22.suse.cz> (raw)
In-Reply-To: <7449f1dc-e51f-7b91-ef73-f69cf3eff294@suse.cz>

On Thu 08-06-17 10:36:13, Vlastimil Babka wrote:
> On 06/08/2017 09:45 AM, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> > 
> > 394e31d2ceb4 ("mem-hotplug: alloc new page from a nearest neighbor node
> > when mem-offline") has duplicated a large part of alloc_migrate_target
> > with some hotplug specific special casing. To be more precise it tried
> > to enfore the allocation from a different node than the original page.
> > As a result the two function diverged in their shared logic, e.g. the
> > hugetlb allocation strategy. Let's unify the two and express different
> > NUMA requirements by the given nodemask. new_node_page will simply
> > exclude the node it doesn't care about and alloc_migrate_target will
> > use all the available nodes. alloc_migrate_target will then learn to
> > migrate hugetlb pages more sanely and use preallocated pool when
> > possible.
> > 
> > Please note that alloc_migrate_target used to call alloc_page resp.
> > alloc_pages_current so the memory policy of the current context which
> > is quite strange when we consider that it is used in the context of
> > alloc_contig_range which just tries to migrate pages which stand in the
> > way.
> > 
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> 
> Acked-by: Vlastimil Babka <vbabka@suse.cz>

Thanks!

> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index 3606104893e0..757410d9f758 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -8,6 +8,7 @@
> >  #include <linux/memory.h>
> >  #include <linux/hugetlb.h>
> >  #include <linux/page_owner.h>
> > +#include <linux/migrate.h>
> >  #include "internal.h"
> >  
> >  #define CREATE_TRACE_POINTS
> > @@ -294,20 +295,5 @@ int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn,
> >  struct page *alloc_migrate_target(struct page *page, unsigned long private,
> >  				  int **resultp)
> >  {
> > -	gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
> > -
> > -	/*
> > -	 * TODO: allocate a destination hugepage from a nearest neighbor node,
> > -	 * accordance with memory policy of the user process if possible. For
> > -	 * now as a simple work-around, we use the next node for destination.
> > -	 */
> > -	if (PageHuge(page))
> > -		return alloc_huge_page_node(page_hstate(compound_head(page)),
> > -					    next_node_in(page_to_nid(page),
> > -							 node_online_map));
> > -
> > -	if (PageHighMem(page))
> > -		gfp_mask |= __GFP_HIGHMEM;
> > -
> > -	return alloc_page(gfp_mask);
> > +	return new_page_nodemask(page, numa_node_id(), &node_states[N_MEMORY]);
> 
> This replaces the N_ONLINE (node_online_map) with N_MEMORY for huge
> pages. Assuming that's OK.

Yes, this is what 231e97e2b8ec ("mem-hotplug: use nodes that contain
memory as mask in new_node_page()") fixed in new_node_page and didn't
care to do on alloc_migrate_target. Another argument to remove the code
duplication. Thanks for pointing out anyway!

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2017-06-08  8:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08  7:45 [PATCH 0/4] more sensible hugetlb migration for hotplug/CMA Michal Hocko
2017-06-08  7:45 ` [PATCH 1/4] mm, memory_hotplug: simplify empty node mask handling in new_node_page Michal Hocko
2017-06-08  8:15   ` Vlastimil Babka
2017-06-08  7:45 ` [PATCH 2/4] hugetlb, memory_hotplug: prefer to use reserved pages for migration Michal Hocko
2017-06-08  8:22   ` Vlastimil Babka
2017-06-08  7:45 ` [PATCH 3/4] mm: unify new_node_page and alloc_migrate_target Michal Hocko
2017-06-08  8:36   ` Vlastimil Babka
2017-06-08  8:40     ` Michal Hocko [this message]
2017-06-08  7:45 ` [RFC PATCH 4/4] hugetlb: add support for preferred node to alloc_huge_page_nodemask Michal Hocko
2017-06-08  8:38   ` Vlastimil Babka
2017-06-12  9:06     ` Michal Hocko
2017-06-12 11:48       ` Michal Hocko
2017-06-12 11:53       ` Vlastimil Babka
2017-06-12 12:20         ` Michal Hocko
2017-06-12 15:21   ` 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=20170608084010.GB19866@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=js1304@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=qiuxishi@huawei.com \
    --cc=vbabka@suse.cz \
    --cc=zhongjiang@huawei.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).