On 01/26/2017 01:09 PM, Michal Hocko wrote:
On Thu 12-01-17 16:37:12, Michal Hocko wrote: [...]+void *kvmalloc_node(size_t size, gfp_t flags, int node) +{ + gfp_t kmalloc_flags = flags; + void *ret; + + /* + * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables) + * so the given set of flags has to be compatible. + */ + WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); + + /* + * Make sure that larger requests are not too disruptive - no OOM + * killer and no allocation failure warnings as we have a fallback + */ + if (size > PAGE_SIZE) + kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN; + + ret = kmalloc_node(size, kmalloc_flags, node); + + /* + * It doesn't really make sense to fallback to vmalloc for sub page + * requests + */ + if (ret || size <= PAGE_SIZE) + return ret; + + return __vmalloc_node_flags(size, node, flags); +} +EXPORT_SYMBOL(kvmalloc_node);While discussing bpf change I've realized that the vmalloc fallback doesn't request __GFP_HIGHMEM. So I've updated the patch to do so. All the current users except for f2fs_kv[zm]alloc which just seemed to forgot or didn't know about the flag. In the next step, I would like to check whether we actually have any __vmalloc* user which would strictly refuse __GFP_HIGHMEM because I do not really see any reason for that and if there is none then I would simply pull __GFP_HIGHMEM handling into the vmalloc. So before I resend the full series again, can I keep acks with the following?
OK! Thanks, Vlastimil -- 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>
