Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753506AbbG2Nax (ORCPT ); Wed, 29 Jul 2015 09:30:53 -0400 Received: from outbound-smtp02.blacknight.com ([81.17.249.8]:48638 "EHLO outbound-smtp02.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751753AbbG2Naw (ORCPT ); Wed, 29 Jul 2015 09:30:52 -0400 Date: Wed, 29 Jul 2015 14:30:43 +0100 From: Mel Gorman To: Vlastimil Babka Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , David Rientjes , Greg Thelen , "Aneesh Kumar K.V" , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Naoya Horiguchi Subject: Re: [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE Message-ID: <20150729133043.GE19352@techsingularity.net> References: <1437749126-25867-1-git-send-email-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1437749126-25867-1-git-send-email-vbabka@suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2743 Lines: 57 On Fri, Jul 24, 2015 at 04:45:23PM +0200, Vlastimil Babka wrote: > The function alloc_pages_exact_node() was introduced in 6484eb3e2a81 ("page > allocator: do not check NUMA node ID when the caller knows the node is valid") No gold stars for that one. > as an optimized variant of alloc_pages_node(), that doesn't allow the node id > to be -1. Unfortunately the name of the function can easily suggest that the > allocation is restricted to the given node and fails otherwise. In truth, the > node is only preferred, unless __GFP_THISNODE is passed among the gfp flags. > > The misleading name has lead to mistakes in the past, see 5265047ac301 ("mm, > thp: really limit transparent hugepage allocation to local node") and > b360edb43f8e ("mm, mempolicy: migrate_to_node should only migrate to node"). > > To prevent further mistakes and provide a convenience function for allocations > truly restricted to a node, this patch makes alloc_pages_exact_node() pass > __GFP_THISNODE to that effect. The previous implementation of The change of what we have now is a good idea. What you have is a solid improvement in my view but I see there are a few different suggestions in the thread. Based on that I think it makes sense to just destroy alloc_pages_exact_node. In the future "exact" in the allocator API will mean "exactly this number of pages". Use your __alloc_pages_node helper and specify __GFP_THISNODE if the caller requires that specific node. > alloc_pages_exact_node() is copied as __alloc_pages_node() which implies it's > an optimized variant of __alloc_pages_node() not intended for general usage. > All three functions are described in the comment. > > Existing callers of alloc_pages_exact_node() are adjusted as follows: > - those that explicitly pass __GFP_THISNODE keep calling > alloc_pages_exact_node(), but the flag is removed from the call __alloc_pages_node(__GFP_THISNODE) would be harder to get wrong in the future > - others are converted to call __alloc_pages_node(). Some may still pass > __GFP_THISNODE if they serve as wrappers that get gfp_flags from higher > layers. > > There's exception of sba_alloc_coherent() which open-codes the check for > nid == -1, so it is converted to use alloc_pages_node() instead. This means > it no longer performs some VM_BUG_ON checks, but otherwise the whole patch > makes no functional changes. > In general, checks for -1 should go away, particularly with new patches. Use NUMA_NO_NODE. -- Mel Gorman SUSE Labs -- 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/