On Wed, Apr 21, 2010 at 10:13 PM, Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 20 Apr 2010, Bob Liu wrote: > >> On Tue, Apr 20, 2010 at 1:47 AM, Christoph Lameter >> <cl@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>