From: Michal Hocko <mhocko@kernel.org>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Balbir Singh <bsingharora@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>,
Minchan Kim <minchan@kernel.org>
Subject: Re: MPOL_BIND on memory only nodes
Date: Wed, 12 Oct 2016 11:43:38 +0200 [thread overview]
Message-ID: <20161012094337.GH17128@dhcp22.suse.cz> (raw)
In-Reply-To: <57FE0184.6030008@linux.vnet.ibm.com>
On Wed 12-10-16 14:55:24, Anshuman Khandual wrote:
> Hi,
>
> We have the following function policy_zonelist() which selects a zonelist
> during various allocation paths. With this, general user space allocations
> (IIUC might not have __GFP_THISNODE) fails while trying to get memory from
> a memory only node without CPUs as the application runs some where else
> and that node is not part of the nodemask.
I am not sure I understand. So you have a task with MPOL_BIND without a
cpu less node in the mask and you are wondering why the memory is not
allocated from that node?
> Why we insist on __GFP_THISNODE ?
AFAIU __GFP_THISNODE just overrides the given node to the policy
nodemask in case the current node is not part of that node mask. In
other words we are ignoring the given node and use what the policy says.
I can see how this can be confusing especially when confronting the
documentation:
* __GFP_THISNODE forces the allocation to be satisified from the requested
* node with no fallbacks or placement policy enforcements.
--
Michal Hocko
SUSE Labs
--
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-12 9:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 9:25 MPOL_BIND on memory only nodes Anshuman Khandual
2016-10-12 9:43 ` Michal Hocko [this message]
2016-10-12 10:38 ` Anshuman Khandual
2016-10-12 11:01 ` Michal Hocko
2016-10-12 13:16 ` Michal Hocko
2016-10-13 9:54 ` Anshuman Khandual
2016-10-13 10:07 ` Michal Hocko
2016-10-13 10:58 ` Anshuman Khandual
2016-10-13 12:51 ` Michal Hocko
2016-10-13 10:24 ` Mel Gorman
2016-10-13 12:38 ` Michal Hocko
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=20161012094337.GH17128@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=vbabka@suse.cz \
/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).