From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932745AbcJLKjv (ORCPT ); Wed, 12 Oct 2016 06:39:51 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:34933 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753834AbcJLKjj (ORCPT ); Wed, 12 Oct 2016 06:39:39 -0400 Date: Wed, 12 Oct 2016 16:08:48 +0530 From: Anshuman Khandual User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michal Hocko , Anshuman Khandual CC: Linux Kernel Mailing List , Linux Memory Management List , Andrew Morton , Mel Gorman , "Aneesh Kumar K.V" , Balbir Singh , Vlastimil Babka , Minchan Kim Subject: Re: MPOL_BIND on memory only nodes References: <57FE0184.6030008@linux.vnet.ibm.com> <20161012094337.GH17128@dhcp22.suse.cz> In-Reply-To: <20161012094337.GH17128@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16101210-0048-0000-0000-000001C7FEC8 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16101210-0049-0000-0000-000046BBEE5E Message-Id: <57FE12B8.4050401@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-12_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610120178 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/12/2016 03:13 PM, Michal Hocko wrote: > 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. My bad. Was playing with some changes to the zonelists rebuild after a memory node hotplug and the order of various zones in them. > > 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? In my experiment, there is a MPOL_BIND call with a CPU less node in the node mask and the memory is not allocated from that CPU less node. Thats because the zone of the CPU less node was absent from the FALLBACK zonelist of the local 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. Right but provided the gfp flag has __GFP_THISNODE in it. In absence of __GFP_THISNODE, the node from the nodemask will not be selected. I still wonder why ? Can we always go to the first node in the nodemask for MPOL_BIND interface calls ? Just curious to know why preference is given to the local node and it's FALLBACK zonelist. > 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. > Yeah, right. Thanks for your reply.