Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1201479 > unrolled thread

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

Started byVlastimil Babka <vbabka@suse.cz>
First post2015-08-06 09:10 +0200
Last post2015-08-06 09:10 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node() Vlastimil Babka <vbabka@suse.cz> - 2015-08-06 09:10 +0200

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

FromVlastimil Babka <vbabka@suse.cz>
Date2015-08-06 09:10 +0200
SubjectRe: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()
Message-ID<pUnto-1Db-9@gated-at.bofh.it>
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/

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web