From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with SMTP id 553B06B01EF for ; Wed, 21 Apr 2010 21:03:14 -0400 (EDT) Received: by pzk11 with SMTP id 11so3016930pzk.28 for ; Wed, 21 Apr 2010 18:03:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1270522777-9216-1-git-send-email-lliubbo@gmail.com> <20100413083855.GS25756@csn.ul.ie> <20100416111539.GC19264@csn.ul.ie> Date: Thu, 22 Apr 2010 09:03:12 +0800 Message-ID: Subject: Re: [PATCH] mempolicy:add GFP_THISNODE when allocing new page From: Bob Liu Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org To: Christoph Lameter Cc: Mel Gorman , kamezawa.hiroyu@jp.fujitsu.com, minchan.kim@gmail.com, akpm@linux-foundation.org, linux-mm@kvack.org, andi@firstfloor.org, rientjes@google.com, lee.schermerhorn@hp.com List-ID: On Wed, Apr 21, 2010 at 10:13 PM, Christoph Lameter wrote: > On Tue, 20 Apr 2010, Bob Liu wrote: > >> On Tue, Apr 20, 2010 at 1:47 AM, Christoph Lameter >> wrote: >> > On Sat, 17 Apr 2010, Bob Liu wrote: >> > >> >> > GFP_THISNODE forces allocation from the node. Without it we will fallback. >> >> > >> >> >> >> Yeah, but I think we shouldn't fallback at this case, what we want is >> >> alloc a page >> >> from exactly the dest node during migrate_to_node(dest).So I added >> >> GFP_THISNODE. >> > >> > Why would we want that? >> > >> >> Because if dest node have no memory, it will fallback to other nodes. >> The dest node's fallback nodes may be nodes in nodemask from_nodes. >> It maybe make circulation ?.(I am not sure.) >> >> What's more,i think it against the user's request. > > The problem is your perception of NUMA against the kernel NUMA design. As > long as you have this problem I would suggest that you do not submit > patches against NUMA functionality in the kernel. > ok :) >> The user wants to move pages from from_nodes to to_nodes, if fallback >> happened, the pages may be moved to other nodes instead of any node in >> nodemask to_nodes. >> I am not sure if the user can expect this and accept. > > Sure the user always had it this way. NUMA allocations (like also > MPOL_INTERLEAVE round robin) are *only* attempts to allocate on specific > nodes. > > There was never a guarantee (until GFP_THISNODE arrived on the scene to > fix SLAB breakage but that was very late in NUMA design of the kernel). > Thanks for your patient reply. Just one small point, why do_move_pages() in migrate.c needs GFP_THISNODE ? -- Regards, --Bob -- 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: email@kvack.org