Thread (49 messages) flat view 49 messages, 9 authors, 2020-03-18

Re: [PATCH 2/4] mm/slub: Use mem_node to allocate a new slab

From: Srikar Dronamraju <hidden>
Date: 2020-03-17 14:51:27
Also in: linux-mm

* Vlastimil Babka [off-list ref] [2020-03-17 14:53:26]:
quoted
quoted
quoted
Mitigate this by allocating the new slab from the node_numa_mem.
Are you sure this is really needed and the other 3 patches are not enough for
the current SLUB code to work as needed? It seems you are changing the semantics
here...
The other 3 patches are not enough because we don't carry the searchnode
when the actual alloc_pages_node gets called. 

With only the 3 patches, we see the above Panic, its signature is slightly
different from what Sachin first reported and which I have carried in 1st
patch.
Ah, I see. So that's the missing pgdat after your series [1] right?
Yes the pgdat would be missing after my cpuless, memoryless node patchset.
However..
That sounds like an argument for Michal's suggestions that pgdats exist and have
correctly populated zonelists for all possible nodes.
Only the first patch in this series would be affected by pgdat existing or
not.  Even if the pgdat existed, the NODE_DATA[nid]->node_present_pages
would be 0. Right? So it would look at node_to_mem_node(). And since node 0 is
cpuless it would return 0. If we pass this node 0 (which is memoryless/cpuless) to
alloc_pages_node. Please note I am only setting node_numa_mem only
for offline nodes. However we could change this to set for all offline and
memoryless nodes.
node_to_mem_node() could be just a shortcut for the first zone's node in the
zonelist, so that fallback follows the topology.

[1]
https://lore.kernel.org/linuxppc-dev/20200311110237.5731-1-srikar@linux.vnet.ibm.com/t/#m76e5b4c4084380b1d4b193d5aa0359b987f2290e (local)


-- 
Thanks and Regards
Srikar Dronamraju
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help