From: Vlastimil Babka <vbabka@suse.cz>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] mm, mempolicy: clean up __GFP_THISNODE confusion in policy_zonelist
Date: Fri, 21 Oct 2016 14:08:19 +0200 [thread overview]
Message-ID: <c8f66d33-f2e9-c29d-6cfd-9eebb4832ebe@suse.cz> (raw)
In-Reply-To: <877f92ue91.fsf@linux.vnet.ibm.com>
On 10/21/2016 01:34 PM, Aneesh Kumar K.V wrote:
> Michal Hocko <mhocko@kernel.org> writes:
>>
>
> For both MPOL_PREFERED and MPOL_INTERLEAVE we pick the zone list from
> the node other than the current running node. Why don't we do that for
> MPOL_BIND ?ie, if the current node is not part of the policy node mask
> why are we not picking the first node from the policy node mask for
> MPOL_BIND ?
For MPOL_PREFERED and MPOL_INTERLEAVE we got some explicit preference of nodes,
so it makes sense that the nodes in the zonelist we pick are ordered by the
distance from that node, regardless of current node.
For MPOL_BIND, we don't have preferences but restrictions. If the current cpu is
from a node within the restriction, then great. If it's not, finding a node
according to distance from current cpu is probably less arbitrary than by
distance from the node that happens to have the lowest id in the node mask?
> -aneesh
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-10-21 12:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 12:59 [PATCH] mm, mempolicy: clean up __GFP_THISNODE confusion in policy_zonelist Michal Hocko
2016-10-18 9:44 ` Vlastimil Babka
2016-10-21 11:34 ` Aneesh Kumar K.V
2016-10-21 11:52 ` Michal Hocko
2016-10-21 12:08 ` Vlastimil Babka [this message]
2016-10-21 12:25 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8f66d33-f2e9-c29d-6cfd-9eebb4832ebe@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).