On Mon 27-02-17 11:32:50, Tahsin Erdogan wrote:

quoted

quoted

quoted

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>