Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()

2015-08-06 Thread Vlastimil Babka

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.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()

2015-07-30 Thread Vlastimil Babka
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().

Suggested-by: Christoph Lameter c...@linux.com
Signed-off-by: Vlastimil Babka vba...@suse.cz
Acked-by: David Rientjes rient...@google.com
Acked-by: Mel Gorman mgor...@techsingularity.net
---
 include/linux/gfp.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 4a12cae2..f92cbd2 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -318,13 +318,14 @@ __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int 
order)
 
 /*
  * Allocate pages, preferring the node given as nid. When nid == NUMA_NO_NODE,
- * prefer the current CPU's node. Otherwise node must be valid and online.
+ * prefer the current CPU's closest node. Otherwise node must be valid and
+ * online.
  */
 static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
unsigned int order)
 {
if (nid == NUMA_NO_NODE)
-   nid = numa_node_id();
+   nid = numa_mem_id();
 
return __alloc_pages_node(nid, gfp_mask, order);
 }
-- 
2.4.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()

2015-07-30 Thread Johannes Weiner
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? Is this for callers doing NUMA_NO_NODE with __GFP_THISZONE?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()

2015-07-30 Thread Christoph Lameter
On Thu, 30 Jul 2015, 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().

 Suggested-by: Christoph Lameter c...@linux.com
 Signed-off-by: Vlastimil Babka vba...@suse.cz
 Acked-by: David Rientjes rient...@google.com
 Acked-by: Mel Gorman mgor...@techsingularity.net

You can add my ack too if it helps.

Acked-by: Christoph Lameter c...@linux.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev