Messages in this thread | | | From | KOSAKI Motohiro <> | Date | Tue, 9 Apr 2013 21:56:58 -0400 | Subject | Re: [PATCH 09/10] memory-hotplug: enable memory hotplug to handle hugepage |
| |
On Tue, Apr 9, 2013 at 6:43 PM, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> wrote: > On Tue, Apr 09, 2013 at 05:27:44PM -0400, KOSAKI Motohiro wrote: >> >> 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. > > MIGRATE_ISOLTE is changed only within the range [start_pfn, end_pfn) > given as the argument of __offline_pages (see also start_isolate_page_range), > so it's set only for pages within the single memblock to be offlined.
When partial memory hot remove, that's correct behavior. different node is not required.
> BTW, in previous discussion I already agreed with checking migrate type > in hugepage allocation code (maybe it will be in dequeue_huge_page_vma(),) > so what you concern should be solved in the next post.
Umm.. Maybe I missed such discussion. Do you have a pointer?
>> > 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. > > OK. So I think about "allocation in the nearest neighbor node", > although it can be in separate patch if it's hard to implement.
That's fine.
| |