Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers
From: Michal Hocko
Date: Thu Jan 26 2017 - 07:10:13 EST
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?