Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753925AbbGXUjw (ORCPT ); Fri, 24 Jul 2015 16:39:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:43711 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbbGXUju (ORCPT ); Fri, 24 Jul 2015 16:39:50 -0400 Message-ID: <55B2A292.7080503@suse.cz> Date: Fri, 24 Jul 2015 22:39:46 +0200 From: Vlastimil Babka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: David Rientjes , Christoph Lameter CC: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Mel Gorman , Greg Thelen , "Aneesh Kumar K.V" , Pekka Enberg , Joonsoo Kim , Naoya Horiguchi Subject: Re: [RFC v2 4/4] mm: fallback for offline nodes in alloc_pages_node References: <1437749126-25867-1-git-send-email-vbabka@suse.cz> <1437749126-25867-4-git-send-email-vbabka@suse.cz> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2655 Lines: 60 On 24.7.2015 21:54, David Rientjes wrote: > On Fri, 24 Jul 2015, Christoph Lameter wrote: > >> On Fri, 24 Jul 2015, Vlastimil Babka wrote: >> >>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h >>> index 531c72d..104a027 100644 >>> --- a/include/linux/gfp.h >>> +++ b/include/linux/gfp.h >>> @@ -321,8 +321,12 @@ static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask, >>> unsigned int order) >>> { >>> /* Unknown node is current (or closest) node */ >>> - if (nid == NUMA_NO_NODE) >>> + if (nid == NUMA_NO_NODE) { >>> nid = numa_mem_id(); >>> + } else if (!node_online(nid)) { >>> + VM_WARN_ON(!node_online(nid)); >>> + nid = numa_mem_id(); >>> + } >> >> I would think you would only want this for debugging purposes. The >> overwhelming majority of hardware out there has no memory >> onlining/offlining capability after all and this adds the overhead to each >> call to alloc_pages_node. >> >> Make this dependo n CONFIG_VM_DEBUG or some such thing? >> > > Yeah, the suggestion was for VM_WARN_ON() in the conditional, but the > placement has changed somewhat because of the new __alloc_pages_node(). I > think > > else if (VM_WARN_ON(!node_online(nid))) > nid = numa_mem_id(); > > should be fine since it only triggers for CONFIG_DEBUG_VM. Um, so on your original suggestion I thought that you assumed that the condition inside VM_WARN_ON is evaluated regardless of CONFIG_DEBUG_VM, it just will or will not generate a warning. Which is how BUG_ON works, but VM_WARN_ON (and VM_BUG_ON) doesn't. IIUC VM_WARN_ON() with !CONFIG_DEBUG_VM will always be false. Because I didn't think you would suggest the "nid = numa_mem_id()" for !node_online(nid) fixup would happen only for CONFIG_DEBUG_VM kernels. But it seems that you do suggest that? I would understand if the fixup (correcting an offline node to some that's online) was done regardless of DEBUG_VM, and DEBUG_VM just switched between silent and noisy fixup. But having a debug option alter the outcome seems wrong? Am I correct that passing an offline node is not fatal, just the zonelist will be empty and the allocation will fail? Now without DEBUG_VM it would silently fail, and with DEBUG_VM it would warn, but succeed on another node. So either we do fixup regardless of DEBUG_VM, or drop this patch, as the VM_WARN_ON(!node_online(nid)) is already done in __alloc_pages_node() thanks to patch 2/4? -- 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/