Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754437AbbHFHAQ (ORCPT ); Thu, 6 Aug 2015 03:00:16 -0400 Received: from mx2.suse.de ([195.135.220.15]:50060 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbbHFHAO (ORCPT ); Thu, 6 Aug 2015 03:00:14 -0400 Subject: Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node() To: Johannes Weiner References: <1438274071-22551-1-git-send-email-vbabka@suse.cz> <1438274071-22551-3-git-send-email-vbabka@suse.cz> <20150730174112.GC15257@cmpxchg.org> Cc: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, Mel Gorman , David Rientjes , Greg Thelen , "Aneesh Kumar K.V" , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Naoya Horiguchi , linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, cbe-oss-dev@lists.ozlabs.org, kvm@vger.kernel.org, Mel Gorman From: Vlastimil Babka Message-ID: <55C305F5.8050005@suse.cz> Date: Thu, 6 Aug 2015 09:00:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150730174112.GC15257@cmpxchg.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1470 Lines: 35 On 07/30/2015 07:41 PM, Johannes Weiner wrote: > On Thu, Jul 30, 2015 at 06:34:31PM +0200, Vlastimil Babka wrote: >> numa_mem_id() is able to handle allocation from CPUs on memory-less nodes, >> so it's a more robust fallback than the currently used numa_node_id(). > > Won't it fall through to the next closest memory node in the zonelist > anyway? Right, I would expect the zonelist of memoryless node to be the same as of the closest node. Documentation/vm/numa seems to agree. Is this for callers doing NUMA_NO_NODE with __GFP_THISZONE? I guess that's the only scenario where that matters, yeah. And there might well be no such caller now, but maybe some will sneak in without the author testing on a system with memoryless node. Note that with !CONFIG_HAVE_MEMORYLESS_NODES, numa_mem_id() just does numa_node_id(). So yeah I think "a more robust fallback" is correct :) But let's put it explicitly in changelog then: ----8<---- alloc_pages_node() might fail when called with NUMA_NO_NODE and __GFP_THISNODE on a CPU belonging to a memoryless node. To make the local-node fallback more robust and prevent such situations, use numa_mem_id(), which was introduced for similar scenarios in the slab context. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/