From: Andi Kleen <andi@firstfloor.org>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, 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>,
linux-kernel@vger.kernel.org,
Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v3 0/8] extend hugepage migration
Date: Fri, 19 Jul 2013 17:33:32 +0200 [thread overview]
Message-ID: <20130719153332.GG6123@two.firstfloor.org> (raw)
In-Reply-To: <1374183272-10153-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On Thu, Jul 18, 2013 at 05:34:24PM -0400, Naoya Horiguchi wrote:
> Here is the 3rd version of hugepage migration patchset.
> I rebased it onto v3.11-rc1 and applied most of your feedbacks.
>
> Some works referred to in previous discussion (shown below) are not included
> in this patchset, but likely to be done after this work.
> - using page walker in check_range
> - split page table lock for pmd/pud based hugepage (maybe applicable to thp)
I did a quick read through the patchkit and it looks all good to me.
It also closes a long standing gap. Thanks!
Acked-by: Andi Kleen <ak@linux.intel.com>
> Hugepage migration of 1GB hugepage is not enabled for now, because
> I'm not sure whether users of 1GB hugepage really want it.
> We need to spare free hugepage in order to do migration, but I don't
> think that users want to 1GB memory to idle for that purpose
> (currently we can't expand/shrink 1GB hugepage pool after boot).
I think we'll need 1GB migration sooner or later. As memory sizes
go up 1GB use will be more common, and the limitation of not
expanding/shrinking 1GB will be eventually fixed.
It would be just a straight forward extension of your patchkit,
right?
-Andi
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, 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>,
linux-kernel@vger.kernel.org,
Naoya Horiguchi <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v3 0/8] extend hugepage migration
Date: Fri, 19 Jul 2013 17:33:32 +0200 [thread overview]
Message-ID: <20130719153332.GG6123@two.firstfloor.org> (raw)
In-Reply-To: <1374183272-10153-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On Thu, Jul 18, 2013 at 05:34:24PM -0400, Naoya Horiguchi wrote:
> Here is the 3rd version of hugepage migration patchset.
> I rebased it onto v3.11-rc1 and applied most of your feedbacks.
>
> Some works referred to in previous discussion (shown below) are not included
> in this patchset, but likely to be done after this work.
> - using page walker in check_range
> - split page table lock for pmd/pud based hugepage (maybe applicable to thp)
I did a quick read through the patchkit and it looks all good to me.
It also closes a long standing gap. Thanks!
Acked-by: Andi Kleen <ak@linux.intel.com>
> Hugepage migration of 1GB hugepage is not enabled for now, because
> I'm not sure whether users of 1GB hugepage really want it.
> We need to spare free hugepage in order to do migration, but I don't
> think that users want to 1GB memory to idle for that purpose
> (currently we can't expand/shrink 1GB hugepage pool after boot).
I think we'll need 1GB migration sooner or later. As memory sizes
go up 1GB use will be more common, and the limitation of not
expanding/shrinking 1GB will be eventually fixed.
It would be just a straight forward extension of your patchkit,
right?
-Andi
next prev parent reply other threads:[~2013-07-19 15:33 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-18 21:34 [PATCH v3 0/8] extend hugepage migration Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-18 21:34 ` [PATCH 1/8] migrate: make core migration code aware of hugepage Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-19 2:38 ` Hillf Danton
2013-07-19 2:38 ` Hillf Danton
2013-07-19 3:18 ` Naoya Horiguchi
2013-07-19 3:18 ` Naoya Horiguchi
2013-07-19 4:04 ` Hillf Danton
2013-07-19 4:04 ` Hillf Danton
2013-07-19 5:09 ` Naoya Horiguchi
2013-07-19 5:09 ` Naoya Horiguchi
2013-07-24 2:28 ` Wanpeng Li
2013-07-24 2:28 ` Wanpeng Li
2013-07-18 21:34 ` [PATCH 2/8] soft-offline: use migrate_pages() instead of migrate_huge_page() Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-24 2:40 ` Wanpeng Li
2013-07-24 2:40 ` Wanpeng Li
2013-07-18 21:34 ` [PATCH 3/8] migrate: add hugepage migration code to migrate_pages() Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-19 3:05 ` Hillf Danton
2013-07-19 3:05 ` Hillf Danton
2013-07-19 4:13 ` Naoya Horiguchi
2013-07-19 4:13 ` Naoya Horiguchi
2013-07-24 3:33 ` Wanpeng Li
2013-07-24 3:33 ` Wanpeng Li
2013-07-18 21:34 ` [PATCH 4/8] migrate: add hugepage migration code to move_pages() Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-19 3:36 ` Hillf Danton
2013-07-19 3:36 ` Hillf Danton
2013-07-19 4:36 ` Naoya Horiguchi
2013-07-19 4:36 ` Naoya Horiguchi
2013-07-24 3:41 ` Wanpeng Li
2013-07-24 3:41 ` Wanpeng Li
2013-07-18 21:34 ` [PATCH 5/8] mbind: add hugepage migration code to mbind() Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-24 3:43 ` Wanpeng Li
2013-07-24 3:43 ` Wanpeng Li
2013-07-18 21:34 ` [PATCH 6/8] migrate: remove VM_HUGETLB from vma flag check in vma_migratable() Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-19 5:26 ` Hillf Danton
2013-07-19 5:26 ` Hillf Danton
2013-07-24 3:45 ` Wanpeng Li
2013-07-24 3:45 ` Wanpeng Li
2013-07-18 21:34 ` [PATCH 7/8] memory-hotplug: enable memory hotplug to handle hugepage Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-19 5:40 ` Hillf Danton
2013-07-19 5:40 ` Hillf Danton
2013-07-19 14:39 ` Naoya Horiguchi
2013-07-19 14:39 ` Naoya Horiguchi
2013-07-20 10:04 ` Hillf Danton
2013-07-20 10:04 ` Hillf Danton
2013-07-24 6:10 ` Wanpeng Li
2013-07-24 6:10 ` Wanpeng Li
[not found] ` <51ef6fd0.1019310a.5683.345bSMTPIN_ADDED_BROKEN@mx.google.com>
2013-07-24 6:26 ` Naoya Horiguchi
2013-07-24 6:26 ` Naoya Horiguchi
2013-07-18 21:34 ` [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable Naoya Horiguchi
2013-07-18 21:34 ` Naoya Horiguchi
2013-07-24 3:46 ` Wanpeng Li
2013-07-24 3:46 ` Wanpeng Li
2013-07-19 15:33 ` Andi Kleen [this message]
2013-07-19 15:33 ` [PATCH v3 0/8] extend hugepage migration Andi Kleen
2013-07-19 15:49 ` Naoya Horiguchi
2013-07-19 15:49 ` Naoya Horiguchi
2013-07-19 17:33 ` Andi Kleen
2013-07-19 17:33 ` Andi Kleen
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=20130719153332.GG6123@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.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=mgorman@suse.de \
--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 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.