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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

>
> And mel concerned that
> ====
> This appears to be a valid bug fix.  I agree that the way things are structured
> that __GFP_THISNODE should be used in new_node_page(). But maybe a follow-on
> patch is also required. The behaviour is now;
>
> o new_node_page will not return NULL if the target node is empty (fine).
> o migrate_pages will translate this into -ENOMEM (fine)
> o do_migrate_pages breaks early if it gets -ENOMEM ?
>
> It's the last part I'd like you to double check. migrate_pages() takes a
> nodemask of allowed nodes to migrate to. Rather than sending this down
> to the allocator, it iterates over the nodes allowed in the mask. If one
> of those nodes is full, it returns -ENOMEM.
>
> If -ENOMEM is returned from migrate_pages, should it not move to the
> next node?
> ====

?? It will move onto the next node if you leave things as is. If you add
GFP_THISNODE then you can get NULL back from the page allocator because
there is no memory on the local node. Without GFP_THISNODe the allocation
will fallback.

> In my opinion, when we want to preserve the relative position of the page to
> the beginning of the node set, early return is ok. Else should try to alloc the
> new page from the next node(to_nodes).

???

> So I added retry path to allocate new page from next node only when
> from_nodes' weight is different from to_nodes', this case the user should
> konw the relative position of the page to the beginning of the node set
> can be changed.

There is no point in your patch since the functionality is already there
without it.

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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]