Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1201479 > unrolled thread
| Started by | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| First post | 2015-08-06 09:10 +0200 |
| Last post | 2015-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.
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
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2015-08-06 09:10 +0200 |
| Subject | Re: [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/
Back to top | Article view | linux.kernel
csiph-web