Re: [patch 1/2] mm: remove GFP_THISNODE

[Vlastimil Babka]

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