Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964885Ab3DIV2H (ORCPT ); Tue, 9 Apr 2013 17:28:07 -0400 Received: from mail-ob0-f182.google.com ([209.85.214.182]:48914 "EHLO mail-ob0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934470Ab3DIV2F (ORCPT ); Tue, 9 Apr 2013 17:28:05 -0400 MIME-Version: 1.0 In-Reply-To: <1365538036-pu7x5mck-mutt-n-horiguchi@ah.jp.nec.com> References: <1363983835-20184-1-git-send-email-n-horiguchi@ah.jp.nec.com> <1363983835-20184-10-git-send-email-n-horiguchi@ah.jp.nec.com> <515F68BB.3010601@gmail.com> <1365538036-pu7x5mck-mutt-n-horiguchi@ah.jp.nec.com> From: KOSAKI Motohiro Date: Tue, 9 Apr 2013 17:27:44 -0400 Message-ID: Subject: Re: [PATCH 09/10] memory-hotplug: enable memory hotplug to handle hugepage To: Naoya Horiguchi Cc: "linux-mm@kvack.org" , Andrew Morton , Mel Gorman , Hugh Dickins , Andi Kleen , Hillf Danton , Michal Hocko , LKML Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1311 Lines: 31 >> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/