From: KOSAKI Motohiro <kosaki.motohiro@gmail.com> To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Hugh Dickins <hughd@google.com>, Andi Kleen <andi@firstfloor.org>, Hillf Danton <dhillf@gmail.com>, Michal Hocko <mhocko@suse.cz>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 09/10] memory-hotplug: enable memory hotplug to handle hugepage Date: Tue, 9 Apr 2013 17:27:44 -0400 [thread overview] Message-ID: <CAHGf_=o+GQ9PJy=rkO1zxhd81NpyTvDQA7phN8StX2+EQ+ZE=g@mail.gmail.com> (raw) In-Reply-To: <1365538036-pu7x5mck-mutt-n-horiguchi@ah.jp.nec.com> >> numa_node_id() is really silly. This might lead to allocate from offlining node. > > Right, it should've been alloc_huge_page(). > >> and, offline_pages() should mark hstate as isolated likes normal pages for prohibiting >> new allocation at first. > > It seems that alloc_migrate_target() calls alloc_page() for normal pages > and the destination pages can be in the same node with the source pages > (new page allocation from the same memblock are prohibited.) No. It can't. memory hotplug change buddy attribute to MIGRATE_ISOLTE at first. then alloc_page() never allocate from source node. however huge page don't use buddy. then we need another trick. > So if we want to avoid new page allocation from the same node, > this is the problem both for normal and huge pages. > > BTW, is it correct to think that all users of memory hotplug assume > that they want to hotplug a whole node (not the part of it?) Both are valid use case. admin can isolate a part of memory for isolating broken memory range. but I'm sure almost user want to remove whole node.
WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com> To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mel@csn.ul.ie>, Hugh Dickins <hughd@google.com>, Andi Kleen <andi@firstfloor.org>, Hillf Danton <dhillf@gmail.com>, Michal Hocko <mhocko@suse.cz>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 09/10] memory-hotplug: enable memory hotplug to handle hugepage Date: Tue, 9 Apr 2013 17:27:44 -0400 [thread overview] Message-ID: <CAHGf_=o+GQ9PJy=rkO1zxhd81NpyTvDQA7phN8StX2+EQ+ZE=g@mail.gmail.com> (raw) In-Reply-To: <1365538036-pu7x5mck-mutt-n-horiguchi@ah.jp.nec.com> >> numa_node_id() is really silly. This might lead to allocate from offlining node. > > Right, it should've been alloc_huge_page(). > >> and, offline_pages() should mark hstate as isolated likes normal pages for prohibiting >> new allocation at first. > > It seems that alloc_migrate_target() calls alloc_page() for normal pages > and the destination pages can be in the same node with the source pages > (new page allocation from the same memblock are prohibited.) No. It can't. memory hotplug change buddy attribute to MIGRATE_ISOLTE at first. then alloc_page() never allocate from source node. however huge page don't use buddy. then we need another trick. > So if we want to avoid new page allocation from the same node, > this is the problem both for normal and huge pages. > > BTW, is it correct to think that all users of memory hotplug assume > that they want to hotplug a whole node (not the part of it?) Both are valid use case. admin can isolate a part of memory for isolating broken memory range. but I'm sure almost user want to remove whole node. -- 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>
next prev parent reply other threads:[~2013-04-09 21:28 UTC|newest] Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-03-22 20:23 [PATCH v2 0/10] extend hugepage migration Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-22 20:23 ` [PATCH 01/10] migrate: add migrate_entry_wait_huge() Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-23 15:55 ` Rik van Riel 2013-03-23 15:55 ` Rik van Riel 2013-03-25 10:13 ` Michal Hocko 2013-03-25 10:13 ` Michal Hocko 2013-03-26 4:25 ` Naoya Horiguchi 2013-03-26 4:25 ` Naoya Horiguchi 2013-04-05 20:33 ` KOSAKI Motohiro 2013-04-05 20:33 ` KOSAKI Motohiro 2013-04-08 20:00 ` Naoya Horiguchi 2013-04-08 20:00 ` Naoya Horiguchi 2013-04-05 20:33 ` KOSAKI Motohiro 2013-04-05 20:33 ` KOSAKI Motohiro 2013-03-22 20:23 ` [PATCH 02/10] migrate: make core migration code aware of hugepage Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-25 10:57 ` Michal Hocko 2013-03-25 10:57 ` Michal Hocko 2013-03-26 4:33 ` Naoya Horiguchi 2013-03-26 4:33 ` Naoya Horiguchi 2013-03-26 8:49 ` Michal Hocko 2013-03-26 8:49 ` Michal Hocko 2013-04-05 20:41 ` KOSAKI Motohiro 2013-04-05 20:41 ` KOSAKI Motohiro 2013-03-22 20:23 ` [PATCH 03/10] soft-offline: use migrate_pages() instead of migrate_huge_page() Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-25 12:31 ` Michal Hocko 2013-03-25 12:31 ` Michal Hocko 2013-03-26 4:34 ` Naoya Horiguchi 2013-03-26 4:34 ` Naoya Horiguchi 2013-03-26 9:49 ` Michal Hocko 2013-03-26 9:49 ` Michal Hocko 2013-03-26 20:35 ` Naoya Horiguchi 2013-03-26 20:35 ` Naoya Horiguchi 2013-03-27 13:00 ` Michal Hocko 2013-03-27 13:00 ` Michal Hocko 2013-04-05 21:11 ` KOSAKI Motohiro 2013-04-05 21:11 ` KOSAKI Motohiro 2013-03-26 11:29 ` Aneesh Kumar K.V 2013-03-26 11:29 ` Aneesh Kumar K.V 2013-03-27 13:52 ` Michal Hocko 2013-03-27 13:52 ` Michal Hocko 2013-03-27 19:19 ` Naoya Horiguchi 2013-03-27 19:19 ` Naoya Horiguchi 2013-03-28 8:53 ` Michal Hocko 2013-03-28 8:53 ` Michal Hocko 2013-03-29 5:26 ` Aneesh Kumar K.V 2013-03-29 5:26 ` Aneesh Kumar K.V 2013-03-29 9:36 ` Michal Hocko 2013-03-29 9:36 ` Michal Hocko 2013-04-01 5:13 ` Aneesh Kumar K.V 2013-04-01 5:13 ` Aneesh Kumar K.V 2013-04-02 9:45 ` Michal Hocko 2013-04-02 9:45 ` Michal Hocko 2013-03-22 20:23 ` [PATCH 04/10] migrate: clean up migrate_huge_page() Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-04-05 21:13 ` KOSAKI Motohiro 2013-04-05 21:13 ` KOSAKI Motohiro 2013-03-22 20:23 ` [PATCH 05/10] migrate: add hugepage migration code to migrate_pages() Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-25 13:04 ` Michal Hocko 2013-03-25 13:04 ` Michal Hocko 2013-03-26 5:13 ` Naoya Horiguchi 2013-03-26 5:13 ` Naoya Horiguchi 2013-03-26 8:55 ` Michal Hocko 2013-03-26 8:55 ` Michal Hocko 2013-04-05 21:17 ` KOSAKI Motohiro 2013-04-05 21:17 ` KOSAKI Motohiro 2013-04-08 20:21 ` Naoya Horiguchi 2013-04-08 20:21 ` Naoya Horiguchi 2013-03-22 20:23 ` [PATCH 06/10] migrate: add hugepage migration code to move_pages() Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-25 13:36 ` Michal Hocko 2013-03-25 13:36 ` Michal Hocko 2013-03-26 7:06 ` Naoya Horiguchi 2013-03-26 7:06 ` Naoya Horiguchi 2013-03-26 10:02 ` Michal Hocko 2013-03-26 10:02 ` Michal Hocko 2013-03-26 20:37 ` Naoya Horiguchi 2013-03-26 20:37 ` Naoya Horiguchi 2013-03-22 20:23 ` [PATCH 07/10] mbind: add hugepage migration code to mbind() Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-25 13:49 ` Michal Hocko 2013-03-25 13:49 ` Michal Hocko 2013-04-05 22:23 ` KOSAKI Motohiro 2013-04-05 22:23 ` KOSAKI Motohiro 2013-04-06 7:04 ` Michal Hocko 2013-04-06 7:04 ` Michal Hocko 2013-04-05 22:18 ` KOSAKI Motohiro 2013-04-05 22:18 ` KOSAKI Motohiro 2013-04-08 20:25 ` Naoya Horiguchi 2013-04-08 20:25 ` Naoya Horiguchi 2013-03-22 20:23 ` [PATCH 08/10] migrate: remove VM_HUGETLB from vma flag check in vma_migratable() Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-22 20:23 ` [PATCH 09/10] memory-hotplug: enable memory hotplug to handle hugepage Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-25 15:09 ` Michal Hocko 2013-03-25 15:09 ` Michal Hocko 2013-03-26 18:23 ` Naoya Horiguchi 2013-03-26 18:23 ` Naoya Horiguchi 2013-03-27 14:19 ` Michal Hocko 2013-03-27 14:19 ` Michal Hocko 2013-03-27 21:29 ` Naoya Horiguchi 2013-03-27 21:29 ` Naoya Horiguchi 2013-03-27 21:58 ` Naoya Horiguchi 2013-03-27 21:58 ` Naoya Horiguchi 2013-03-27 22:55 ` Michal Hocko 2013-03-27 22:55 ` Michal Hocko 2013-03-26 12:01 ` Aneesh Kumar K.V 2013-03-26 12:01 ` Aneesh Kumar K.V 2013-03-27 19:28 ` Naoya Horiguchi 2013-03-27 19:28 ` Naoya Horiguchi 2013-04-06 0:13 ` KOSAKI Motohiro 2013-04-06 0:13 ` KOSAKI Motohiro 2013-04-09 20:07 ` Naoya Horiguchi 2013-04-09 20:07 ` Naoya Horiguchi 2013-04-09 21:27 ` KOSAKI Motohiro [this message] 2013-04-09 21:27 ` KOSAKI Motohiro 2013-04-09 22:43 ` Naoya Horiguchi 2013-04-09 22:43 ` Naoya Horiguchi 2013-04-10 1:56 ` KOSAKI Motohiro 2013-04-10 1:56 ` KOSAKI Motohiro 2013-04-10 2:24 ` Naoya Horiguchi 2013-04-10 2:24 ` Naoya Horiguchi 2013-03-22 20:23 ` [PATCH 10/10] prepare to remove /proc/sys/vm/hugepages_treat_as_movable Naoya Horiguchi 2013-03-22 20:23 ` Naoya Horiguchi 2013-03-25 15:12 ` Michal Hocko 2013-03-25 15:12 ` Michal Hocko 2013-04-06 0:15 ` KOSAKI Motohiro 2013-04-06 0:15 ` KOSAKI Motohiro
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='CAHGf_=o+GQ9PJy=rkO1zxhd81NpyTvDQA7phN8StX2+EQ+ZE=g@mail.gmail.com' \ --to=kosaki.motohiro@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=andi@firstfloor.org \ --cc=dhillf@gmail.com \ --cc=hughd@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=mhocko@suse.cz \ --cc=n-horiguchi@ah.jp.nec.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: linkBe 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.