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