* Vlastimil Babka <vbabka@xxxxxxx> [2020-03-20 09:43:11]: > On 3/20/20 8:46 AM, Srikar Dronamraju wrote: > > * Vlastimil Babka <vbabka@xxxxxxx> [2020-03-19 15:10:19]: > > > >> On 3/19/20 3:05 PM, Srikar Dronamraju wrote: > >> > * Vlastimil Babka <vbabka@xxxxxxx> [2020-03-19 14:47:58]: > >> > > >> > >> No, but AFAICS, such node values are already handled in ___slab_alloc, and > >> cannot reach get_partial(). If you see something I missed, please do tell. > >> > > > > Ah I probably got confused with your previous version where > > alloc_slab_page() was modified. I see no problems with this version. > > Thanks! > > > Sorry for the noise. > > No problem. > > > A question just for my better understanding, > > How worse would it be to set node to numa_mem_id() instead of NUMA_NODE_ID > > when the current node is !N_NORMAL_MEMORY? > Yes, > (I'm assuming you mean s/NUMA_NODE_ID/NUMA_NO_NODE/) > > Well, numa_mem_id() should work too, but it would make the allocation > constrained to the node of current cpu, with all the consequences (deactivating > percpu slab if it was from a different node etc). > > There's no reason why this cpu's node should be the closest node to the one that > was originally requested (but has no memory), so it's IMO pointless or even > suboptimal to constraint to it. This can be revisited in case we get guaranteed > existence of node data with zonelists for all possible nodes, but for now > NUMA_NO_NODE seems the most reasonable fix to me. > Okay. -- Thanks and Regards Srikar Dronamraju
