• M
    mm, mempolicy: clean up __GFP_THISNODE confusion in policy_zonelist · 6d840958
    Michal Hocko 提交于
    __GFP_THISNODE is documented to enforce the allocation to be satisified
    from the requested node with no fallbacks or placement policy
    enforcements.  policy_zonelist seemingly breaks this semantic if the
    current policy is MPOL_MBIND and instead of taking the node it will
    fallback to the first node in the mask if the requested one is not in
    the mask.  This is confusing to say the least because it fact we
    shouldn't ever go that path.  First tasks shouldn't be scheduled on CPUs
    with nodes outside of their mempolicy binding.  And secondly
    policy_zonelist is called only from 3 places:
    
     - huge_zonelist - never should do __GFP_THISNODE when going this path
    
     - alloc_pages_vma - which shouldn't depend on __GFP_THISNODE either
    
     - alloc_pages_current - which uses default_policy id __GFP_THISNODE is
       used
    
    So we shouldn't even need to care about this possibility and can drop
    the confusing code.  Let's keep a WARN_ON_ONCE in place to catch
    potential users and fix them up properly (aka use a different allocation
    function which ignores mempolicy).
    
    [akpm@linux-foundation.org: coding-style fixes]
    Link: http://lkml.kernel.org/r/20161013125958.32155-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
    Acked-by: NVlastimil Babka <vbabka@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    6d840958
mempolicy.c 71.2 KB