Re: [patch for-4.20] Revert "mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask"

From: Michal Hocko
Date: Mon Dec 10 2018 - 03:34:14 EST


On Fri 07-12-18 15:05:28, David Rientjes wrote:
> On Fri, 7 Dec 2018, Michal Hocko wrote:
[...]
> > > Secondly, prior to 89c83fb539f9, alloc_pages_vma() implemented a somewhat
> > > different policy for hugepage allocations, which were allocated through
> > > alloc_hugepage_vma(). For hugepage allocations, if the allocating
> > > process's node is in the set of allowed nodes, allocate with
> > > __GFP_THISNODE for that node (for MPOL_PREFERRED, use that node with
> > > __GFP_THISNODE instead).
> >
> > Why is it wrong to fallback to an explicitly configured mbind mask?
> >
>
> The new_page() case is similar to the shmem_alloc_hugepage() case. Prior
> to 89c83fb539f9 ("mm, thp: consolidate THP gfp handling into
> alloc_hugepage_direct_gfpmask"), shmem_alloc_hugepage() did
> alloc_pages_vma() with hugepage == true, which effected a different
> allocation policy: if the node current is running on is allowed by the
> policy, use __GFP_THISNODE (considering ac5b2c18911ff is reverted, which
> it is in Linus's tree).
>
> After 89c83fb539f9, we lose that and can fallback to remote memory. Since
> the discussion is on-going wrt the NUMA aspects of hugepage allocations,
> it's better to have a stable 4.20 tree while that is being worked out and
> likely deserves separate patches for both new_page() and
> shmem_alloc_hugepage(). For the latter specifically, I assume it would be
> nice to get an Acked-by by Kirill who implemented shmem_alloc_hugepage()
> with hugepage == true back in 4.8 that also had the __GFP_THISNODE
> behavior before the allocation policy is suddenly changed.

This should be a part of the changelog.

--
Michal Hocko
SUSE Labs