On Thu, 28 Apr 2016, Michal Hocko wrote: > On Thu 28-04-16 11:04:05, Mikulas Patocka wrote: > > Acked-by: Mikulas Patocka <mpatocka@xxxxxxxxxx> > > Thanks! > > > BTW. we could also use kvmalloc to complement kvfree, proposed here: > > https://www.redhat.com/archives/dm-devel/2015-July/msg00046.html > > If there are sufficient users (I haven't checked other than quick git > grep on KMALLOC_MAX_SIZE the problem is that kmallocs with large sizes near KMALLOC_MAX_SIZE are unreliable, they'll randomly fail if memory is too fragmented. > and there do not seem that many) who are > sharing the same fallback strategy then why not. But I suspect that some > would rather fallback earlier and even do not attempt larger than e.g. > order-1 requests. > -- > Michal Hocko > SUSE Labs There are many users that use one of these patterns: if (size <= some_threshold) p = kmalloc(size); else p = vmalloc(size); or p = kmalloc(size); if (!p) p = vmalloc(size); For example: alloc_fdmem, seq_buf_alloc, setxattr, getxattr, ipc_alloc, pidlist_allocate, get_pages_array, alloc_bucket_locks, frame_vector_create. If you grep the kernel for vmalloc, you'll find this pattern over and over again. In alloc_large_system_hash, there is table = __vmalloc(size, GFP_ATOMIC, PAGE_KERNEL); - that is clearly wrong because __vmalloc doesn't respect GFP_ATOMIC Mikulas -- 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>