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. > 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). -- 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>