On Fri, 27 Feb 2015, Vlastimil Babka wrote:

quoted

Do you see any issues with either patch 1/2 or patch 2/2 besides the 
s/GFP_TRANSHUGE/GFP_THISNODE/ that is necessary on the changelog?

Well, my point is, what if the node we are explicitly trying to allocate
hugepage on, is in fact not allowed by our cpuset? This could happen in the page
fault case, no? Although in a weird configuration when process can (and really
gets scheduled to run) on a node where it is not allowed to allocate from...

If the process is running a node that is not allowed by the cpuset, then 
alloc_hugepage_vma() now fails with VM_FAULT_FALLBACK.  That was the 
intended policy change of commit 077fcf116c8c ("mm/thp: allocate 
transparent hugepages on local node").

 [ alloc_hugepage_vma() should probably be using numa_mem_id() instead for 
   memoryless node platforms. ]