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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
