All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Greg Thelen <gthelen@google.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE
Date: Wed, 29 Jul 2015 14:30:43 +0100	[thread overview]
Message-ID: <20150729133043.GE19352@techsingularity.net> (raw)
In-Reply-To: <1437749126-25867-1-git-send-email-vbabka@suse.cz>

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

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Greg Thelen <gthelen@google.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE
Date: Wed, 29 Jul 2015 14:30:43 +0100	[thread overview]
Message-ID: <20150729133043.GE19352@techsingularity.net> (raw)
In-Reply-To: <1437749126-25867-1-git-send-email-vbabka@suse.cz>

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2015-07-29 13:30 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24 14:45 [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE Vlastimil Babka
2015-07-24 14:45 ` Vlastimil Babka
2015-07-24 14:45 ` [RFC v2 2/4] mm: unify checks in alloc_pages_node family of functions Vlastimil Babka
2015-07-24 14:45   ` Vlastimil Babka
2015-07-24 20:09   ` David Rientjes
2015-07-24 20:09     ` David Rientjes
2015-07-24 14:45 ` [RFC v2 3/4] mm: use numa_mem_id in alloc_pages_node() Vlastimil Babka
2015-07-24 14:45   ` Vlastimil Babka
2015-07-24 20:09   ` David Rientjes
2015-07-24 20:09     ` David Rientjes
2015-07-29 13:31   ` Mel Gorman
2015-07-29 13:31     ` Mel Gorman
2015-07-24 14:45 ` [RFC v2 4/4] mm: fallback for offline nodes in alloc_pages_node Vlastimil Babka
2015-07-24 14:45   ` Vlastimil Babka
2015-07-24 15:48   ` Christoph Lameter
2015-07-24 15:48     ` Christoph Lameter
2015-07-24 19:54     ` David Rientjes
2015-07-24 19:54       ` David Rientjes
2015-07-24 20:39       ` Vlastimil Babka
2015-07-24 20:39         ` Vlastimil Babka
2015-07-24 23:06         ` David Rientjes
2015-07-24 23:06           ` David Rientjes
2015-07-27 11:29           ` Vlastimil Babka
2015-07-27 11:29             ` Vlastimil Babka
2015-07-24 20:08 ` [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE David Rientjes
2015-07-24 20:08   ` David Rientjes
2015-07-24 20:52   ` Vlastimil Babka
2015-07-24 20:52     ` Vlastimil Babka
2015-07-24 23:09     ` David Rientjes
2015-07-24 23:09       ` David Rientjes
2015-07-27 15:39 ` Johannes Weiner
2015-07-27 15:39   ` Johannes Weiner
2015-07-27 15:47   ` Vlastimil Babka
2015-07-27 15:47     ` Vlastimil Babka
2015-07-29 13:30 ` Mel Gorman [this message]
2015-07-29 13:30   ` Mel Gorman
2015-07-30 14:33   ` Christoph Lameter
2015-07-30 14:33     ` Christoph Lameter
2015-07-30 15:14   ` Johannes Weiner
2015-07-30 15:14     ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150729133043.GE19352@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cl@linux.com \
    --cc=gthelen@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.