From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753061AbcJLLCQ (ORCPT ); Wed, 12 Oct 2016 07:02:16 -0400 Received: from mail-lf0-f45.google.com ([209.85.215.45]:33588 "EHLO mail-lf0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387AbcJLLCD (ORCPT ); Wed, 12 Oct 2016 07:02:03 -0400 Date: Wed, 12 Oct 2016 13:01:58 +0200 From: Michal Hocko To: 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 Message-ID: <20161012110158.GK17128@dhcp22.suse.cz> References: <57FE0184.6030008@linux.vnet.ibm.com> <20161012094337.GH17128@dhcp22.suse.cz> <57FE12B8.4050401@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57FE12B8.4050401@linux.vnet.ibm.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 12-10-16 16:08:48, Anshuman Khandual wrote: > 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. So do I understand this correctly that the issue was caused by non-upstream changes? > >> 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. In absence of __GFP_THISNODE we will use the zonelist for the given node and that should contain even memoryless nodes for the fallback. The nodemask from policy_nodemask() will then make sure that only nodes relevant to the used policy is used. > 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. It is not always a local node. Look at how do_huge_pmd_wp_page_fallback tries to make all the pages into the same node. Also we have alloc_pages_current() which tries to allocate from the local node which should not fallback to the firs node in the policy nodemask. -- Michal Hocko SUSE Labs