Re: [PATCH 2/2] mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask

[Vlastimil Babka]

On 10/22/18 3:30 PM, Michal Hocko wrote:
> On Mon 22-10-18 15:15:38, Vlastimil Babka wrote:
>>> Forgot to add. One notable exception would be that the previous code
>>> would allow to hit
>>> 	WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));
>>> in policy_node if the requested node (e.g. cpu local one) was outside of
>>> the mbind nodemask. This is not possible now. We haven't heard about any
>>> such warning yet so it is unlikely that it happens though.
>>
>> I don't think the previous code could hit the warning, as the hugepage
>> path that would add __GFP_THISNODE didn't call policy_node() (containing
>> the warning) at all. IIRC early of your patch did hit the warning
>> though, which is why you added the MPOL_BIND policy check.
> 
> Are you sure? What prevents node_isset(node, policy_nodemask()) == F and
> fallback to the !huge allocation path?

That can indeed happen, but then the code also skipped the "gfp |=
__GFP_THISNODE" part, right? So the warning wouldn't trigger.

> alloc_pages_vma is usually called
> with the local node and processes shouldn't run off their bounded num
> mask but is that guaranteed? Moreover do_huge_pmd_wp_page_fallback uses
> the former numa binding and that might be outside of the policy mask.
> 
> In any case, as I've said this is highly unlikely to hit which is
> underlined by the lack of reports.
>