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