linux-kernel - Re: MPOL_BIND on memory only nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20161013125143.GN21678@dhcp22.suse.cz>
Date:   Thu, 13 Oct 2016 14:51:44 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc:     Mel Gorman <mgorman@...e.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Balbir Singh <bsingharora@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Minchan Kim <minchan@...nel.org>
Subject: Re: MPOL_BIND on memory only nodes

On Thu 13-10-16 16:28:27, Anshuman Khandual wrote:
> On 10/13/2016 03:37 PM, Michal Hocko wrote:
> > On Thu 13-10-16 15:24:54, Anshuman Khandual wrote:
> > [...]
> >> Which makes the function look like this. Even with these changes, MPOL_BIND is
> >> still going to pick up the local node's zonelist instead of the first node in
> >> policy->v.nodes nodemask. It completely ignores policy->v.nodes which it should
> >> not.
> > 
> > Not really. I have tried to explain earlier. We do not ignore policy
> > nodemask. This one comes from policy_nodemask. We start with the local
> > node but fallback to some of the nodes from the nodemask defined by the
> > policy.
> > 
> 
> Yeah saw your response but did not get that exactly. We dont ignore
> policy nodemask while memory allocation, correct. But my point was
> we are ignoring policy nodemask while selecting zonelist which will
> be used during page allocation. Though the zone contents of both the
> zonelists are likely to be same, would not it be better to get the
> zone list from the nodemask as well ?

Why. Zonelist from the current node should contain all availanle zones
and get_page_from_freelist then filters this zonelist accoring to
mempolicy and nodemask

> Or I am still missing something
> here. The following change is what I am trying to propose.
> 
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index ad1c96a..f60ab80 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1685,14 +1685,7 @@ static struct zonelist *policy_zonelist(gfp_t gfp, struct mempolicy *policy,
>                         nd = policy->v.preferred_node;
>                 break;
>         case MPOL_BIND:
> -               /*
> -                * Normally, MPOL_BIND allocations are node-local within the
> -                * allowed nodemask.  However, if __GFP_THISNODE is set and the
> -                * current node isn't part of the mask, we use the zonelist for
> -                * the first node in the mask instead.
> -                */
> -               if (unlikely(gfp & __GFP_THISNODE) &&
> -                               unlikely(!node_isset(nd, policy->v.nodes)))
> +               if (unlikely(!node_isset(nd, policy->v.nodes)))
>                         nd = first_node(policy->v.nodes);

That shouldn't make much difference as per above.

-- 
Michal Hocko
SUSE Labs