linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, Hugh Dickins <hughd@google.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andi Kleen <andi@firstfloor.org>, Hillf Danton <dhillf@gmail.com>,
	Michal Hocko <mhocko@suse.cz>, Rik van Riel <riel@redhat.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH 5/9] mbind: add hugepage migration code to mbind()
Date: Tue, 10 Sep 2013 15:41:09 +0100	[thread overview]
Message-ID: <20130910144109.GR22421@suse.de> (raw)
In-Reply-To: <1376025702-14818-6-git-send-email-n-horiguchi@ah.jp.nec.com>

On Fri, Aug 09, 2013 at 01:21:38AM -0400, Naoya Horiguchi wrote:
> This patch extends do_mbind() to handle vma with VM_HUGETLB set.
> We will be able to migrate hugepage with mbind(2) after
> applying the enablement patch which comes later in this series.
> 
> ChangeLog v3:
>  - revert introducing migrate_movable_pages
>  - added alloc_huge_page_noerr free from ERR_VALUE
> 
> ChangeLog v2:
>  - updated description and renamed patch title
> 
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Acked-by: Andi Kleen <ak@linux.intel.com>
> Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
> Acked-by: Hillf Danton <dhillf@gmail.com>
> ---
>  include/linux/hugetlb.h |  3 +++
>  mm/hugetlb.c            | 14 ++++++++++++++
>  mm/mempolicy.c          |  4 +++-
>  3 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git v3.11-rc3.orig/include/linux/hugetlb.h v3.11-rc3/include/linux/hugetlb.h
> index bc8d837..d1db007 100644
> --- v3.11-rc3.orig/include/linux/hugetlb.h
> +++ v3.11-rc3/include/linux/hugetlb.h
> @@ -265,6 +265,8 @@ struct huge_bootmem_page {
>  };
>  
>  struct page *alloc_huge_page_node(struct hstate *h, int nid);
> +struct page *alloc_huge_page_noerr(struct vm_area_struct *vma,
> +				unsigned long addr, int avoid_reserve);
>  
>  /* arch callback */
>  int __init alloc_bootmem_huge_page(struct hstate *h);
> @@ -378,6 +380,7 @@ static inline pgoff_t basepage_index(struct page *page)
>  #else	/* CONFIG_HUGETLB_PAGE */
>  struct hstate {};
>  #define alloc_huge_page_node(h, nid) NULL
> +#define alloc_huge_page_noerr(v, a, r) NULL
>  #define alloc_bootmem_huge_page(h) NULL
>  #define hstate_file(f) NULL
>  #define hstate_sizelog(s) NULL
> diff --git v3.11-rc3.orig/mm/hugetlb.c v3.11-rc3/mm/hugetlb.c
> index 649771c..ee764b0 100644
> --- v3.11-rc3.orig/mm/hugetlb.c
> +++ v3.11-rc3/mm/hugetlb.c
> @@ -1195,6 +1195,20 @@ static struct page *alloc_huge_page(struct vm_area_struct *vma,
>  	return page;
>  }
>  
> +/*
> + * alloc_huge_page()'s wrapper which simply returns the page if allocation
> + * succeeds, otherwise NULL. This function is called from new_vma_page(),
> + * where no ERR_VALUE is expected to be returned.
> + */
> +struct page *alloc_huge_page_noerr(struct vm_area_struct *vma,
> +				unsigned long addr, int avoid_reserve)
> +{
> +	struct page *page = alloc_huge_page(vma, addr, avoid_reserve);
> +	if (IS_ERR(page))
> +		page = NULL;
> +	return page;
> +}
> +
>  int __weak alloc_bootmem_huge_page(struct hstate *h)
>  {
>  	struct huge_bootmem_page *m;
> diff --git v3.11-rc3.orig/mm/mempolicy.c v3.11-rc3/mm/mempolicy.c
> index d96afc1..4a03c14 100644
> --- v3.11-rc3.orig/mm/mempolicy.c
> +++ v3.11-rc3/mm/mempolicy.c
> @@ -1183,6 +1183,8 @@ static struct page *new_vma_page(struct page *page, unsigned long private, int *
>  		vma = vma->vm_next;
>  	}
>  
> +	if (PageHuge(page))
> +		return alloc_huge_page_noerr(vma, address, 1);
>  	/*
>  	 * if !vma, alloc_page_vma() will use task or system default policy
>  	 */

It's interesting to note that it will be tricky to configure a system to
allow this sort of migration to succeed.

This call correctly uses avoid_reserve but that does mean that for it
to work that there there must be free pages statically allocated in the
hugepage pool of the destination node or hugepage dynamic pool resizing
must be enabled. The former option is going to waste memory because pages
allocated to the static pool cannot be used for any other purpose and
using dynamic hugepage pool resizing may fail.

It makes me wonder how actually useful generic hugetlbfs page migration
will be in practice. Are there really usecases where the system
administrator is willing to create unused hugepage pools on each node
just to enable migration?

> @@ -1293,7 +1295,7 @@ static long do_mbind(unsigned long start, unsigned long len,
>  					(unsigned long)vma,
>  					MIGRATE_SYNC, MR_MEMPOLICY_MBIND);
>  			if (nr_failed)
> -				putback_lru_pages(&pagelist);
> +				putback_movable_pages(&pagelist);
>  		}
>  
>  		if (nr_failed && (flags & MPOL_MF_STRICT))
> -- 
> 1.8.3.1
> 

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2013-09-10 14:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-09  5:21 [PATCH v5 0/9] extend hugepage migration Naoya Horiguchi
2013-08-09  5:21 ` [PATCH 1/9] migrate: make core migration code aware of hugepage Naoya Horiguchi
2013-09-10 13:51   ` Mel Gorman
2013-09-10 19:18     ` Naoya Horiguchi
2013-08-09  5:21 ` [PATCH 2/9] soft-offline: use migrate_pages() instead of migrate_huge_page() Naoya Horiguchi
2013-08-09  5:21 ` [PATCH 3/9] migrate: add hugepage migration code to migrate_pages() Naoya Horiguchi
2013-08-14 23:41   ` Andrew Morton
2013-08-15  1:15     ` Naoya Horiguchi
2013-09-10 14:33   ` Mel Gorman
2013-09-10 19:45     ` Naoya Horiguchi
2013-08-09  5:21 ` [PATCH 4/9] migrate: add hugepage migration code to move_pages() Naoya Horiguchi
2013-09-28 17:26   ` Borislav Petkov
2013-09-30 15:01     ` Naoya Horiguchi
2013-09-30 16:04       ` Borislav Petkov
2013-09-30 16:08         ` Naoya Horiguchi
2013-11-12 11:56           ` Borislav Petkov
2013-11-14 15:47             ` [PATCH] mm/migrate.c: take returned value of isolate_huge_page()(Re: [PATCH 4/9] migrate: add hugepage migration code to move_pages()) Naoya Horiguchi
2013-11-14 23:11               ` David Rientjes
2013-11-15 15:03                 ` [PATCH] mm/migrate.c: take returned value ofisolate_huge_page()(Re: [PATCH 4/9] migrate: add hugepage migration code tomove_pages()) Naoya Horiguchi
2013-11-15 23:01                   ` David Rientjes
2013-08-09  5:21 ` [PATCH 5/9] mbind: add hugepage migration code to mbind() Naoya Horiguchi
2013-09-10 14:41   ` Mel Gorman [this message]
2013-09-10 21:53     ` Naoya Horiguchi
2013-09-10 22:47       ` Andi Kleen
2013-08-09  5:21 ` [PATCH 6/9] migrate: remove VM_HUGETLB from vma flag check in vma_migratable() Naoya Horiguchi
2013-08-09  5:21 ` [PATCH 7/9] memory-hotplug: enable memory hotplug to handle hugepage Naoya Horiguchi
2013-08-09  5:21 ` [PATCH 8/9] migrate: check movability of hugepage in unmap_and_move_huge_page() Naoya Horiguchi
2013-08-11 17:51   ` Aneesh Kumar K.V
2013-08-09  5:21 ` [PATCH 9/9] prepare to remove /proc/sys/vm/hugepages_treat_as_movable Naoya Horiguchi
2013-08-11 17:43   ` Aneesh Kumar K.V
2013-08-12 18:10     ` Naoya Horiguchi
2013-09-10 14:48   ` Mel Gorman
2013-08-14 23:40 ` [PATCH v5 0/9] extend hugepage migration Andrew Morton
2013-08-15  6:23   ` Naoya Horiguchi
2013-08-15 19:39     ` Andrew Morton
2013-08-15 19:48       ` Naoya Horiguchi

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=20130910144109.GR22421@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dhillf@gmail.com \
    --cc=hughd@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=mhocko@suse.cz \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=nao.horiguchi@gmail.com \
    --cc=riel@redhat.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).