On Fri, 24 Jul 2015, Vlastimil Babka wrote: > > I assume you looked at the collapse_huge_page() case and decided that it > > needs no modification since the gfp mask is used later for other calls? > > Yeah. Not that the memcg charge parts would seem to care about __GFP_THISNODE, > though. > Hmm, not sure that memcg would ever care about __GFP_THISNODE. I wonder if it make more sense to remove setting __GFP_THISNODE in collapse_huge_page()? khugepaged_alloc_page() seems fine with the new alloc_pages_exact_node() semantics. > >> diff --git a/mm/migrate.c b/mm/migrate.c > >> index f53838f..d139222 100644 > >> --- a/mm/migrate.c > >> +++ b/mm/migrate.c > >> @@ -1554,10 +1554,8 @@ static struct page *alloc_misplaced_dst_page(struct page *page, > >> struct page *newpage; > >> > >> newpage = alloc_pages_exact_node(nid, > >> - (GFP_HIGHUSER_MOVABLE | > >> - __GFP_THISNODE | __GFP_NOMEMALLOC | > >> - __GFP_NORETRY | __GFP_NOWARN) & > >> - ~GFP_IOFS, 0); > >> + (GFP_HIGHUSER_MOVABLE | __GFP_NOMEMALLOC | > >> + __GFP_NORETRY | __GFP_NOWARN) & ~GFP_IOFS, 0); > >> > >> return newpage; > >> } > > [snip] > > > > What about the alloc_pages_exact_node() in new_page_node()? > > Oops, seems I missed that one. So the API seems ok otherwise? > Yup! And I believe that this patch doesn't cause any regression after the new_page_node() issue is fixed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>