On Mon 27-02-17 11:32:50, Tahsin Erdogan wrote: > >> > > >> > Yes, this prevents adding more pcpu chunks and so cause "atomic" allocations > >> > to fail more easily. > >> > >> Then I fail to see what is the problem you are trying to fix. > > > > To be more specific. Could you describe what more can we do in the > > vmalloc layer for GFP_NOWAIT allocations? They certainly cannot sleep > > and cannot perform the reclaim so you have to rely on the background > > work. > > The main problem that I am trying to fix is in percpu.c code. It > currently doesn't even attempt to call vmalloc() for GFP_NOWAIT > case. It solely relies on the background allocator to replenish the > reserves. I would like percpu.c to call __vmalloc(GFP_NOWAIT) inline > and see whether that succeeds. If that fails, it is fair to fail the > call. OK, that wasn't really clean from the patch to me. I guess it would be much more easier if a preparatory patch did the gfp mask propagation and then have patch that changes the pcpu allocator the way you need. > For this to work, __vmalloc() should be ready to serve a caller > that is holding a spinlock. The might_sleep() in alloc_vmap_area() > basically prevents us calling vmalloc in this context. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
