On 27.2.2015 23:31, David Rientjes wrote:
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").
Ah, right, didn't realize that mempolicy also takes that into account.
Thanks for removing the exception anyway.
[ 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>