On Sat 25-02-17 20:38:29, Tahsin Erdogan wrote: > When pcpu_alloc() is called with gfp != GFP_KERNEL, the likelihood of > a failure is higher than GFP_KERNEL case. This is mainly because > pcpu_alloc() relies on previously allocated reserves and does not make > an effort to add memory to its pools for non-GFP_KERNEL case. Who is going to use a different mask? > This issue is somewhat mitigated by kicking off a background work when > a memory allocation failure occurs. But this doesn't really help the > original victim of allocation failure. > > This problem affects blkg_lookup_create() callers on machines with a > lot of cpus. > > This patch reduces failure cases by trying to expand the memory pools. > It passes along gfp flag so it is safe to allocate memory this way. > > To make this work, a gfp flag aware vmalloc_gfp() function is added. > Also, locking around vmap_area_lock has been updated to save/restore > irq flags. This was needed to avoid a lockdep problem between > request_queue->queue_lock and vmap_area_lock. We already have __vmalloc_gfp, why this cannot be used? Also note that vmalloc dosn't really support arbitrary gfp flags. One have to be really careful because there are some internal allocations which are hardcoded GFP_KERNEL. Also this patch doesn't really add any new callers so it is hard to tell whether what you do actually makes sense and is correct. -- 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>