# Re: \[patch 1/2\] mm: remove GFP\_THISNODE

- From: David Rientjes \<rientjes@google.com\>
- Date: 2015-02-27 22:31:49 
- List: netdev
- Page: https://ratatoskr.run/netdev/2015/02/4439316
- Thread: https://ratatoskr.run/linux-mm/2015/02/4437856/t.md

```text
On Fri, 27 Feb 2015, Vlastimil Babka wrote:

> > 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. ]
```