[lkml]   [2018]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask
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.

 \ /
  Last update: 2018-10-22 15:36    [W:0.091 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site