On Mon, 24 Feb 2020, Michal Hocko wrote: > Hmm, nasty. Is there any reason why kmalloc_node behaves differently > from the page allocator? The page allocator will do the same thing if you pass GFP_THISNODE and insist on allocating memory from a node that does not exist. > > > A short summary. kmalloc_node blows up when trying to allocate from a > > > memory less node. > > > > Use kmalloc instead? And set a memory allocation policy? > > The current code (memcg_expand_one_shrinker_map resp. memcg_alloc_shrinker_maps) > already use kvmalloc. Kirill's patch wanted to make those data structure > on the respective node and kvmalloc_node sounded like the right thing to > do. It comes as a surprise that the kernel simply blows up on a memory > less node rather than falling back to a close node gracefully. I suspect > this already happens when the target node is out of memory, right? No. If the target node is out of memory then direct reclaim is going to be invovked. > How would a memory allocation policy help in this case btw.? It would allow fallback to other nodes.
