Re: [PATCH] mempolicy:add GFP_THISNODE when allocing new page

[Bob Liu <lliubbo@gmail.com>]

On Wed, Apr 21, 2010 at 10:13 PM, Christoph Lameter
<cl@linux-foundation.org> wrote:
> On Tue, 20 Apr 2010, Bob Liu wrote:
>
>> On Tue, Apr 20, 2010 at 1:47 AM, Christoph Lameter
>> <cl@linux-foundation.org> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>