lkml.org 
[lkml]   [2016]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] md: simplify free_params for kmalloc vs vmalloc fallback


On Thu, 28 Apr 2016, Michal Hocko wrote:

> On Thu 28-04-16 11:04:05, Mikulas Patocka wrote:
> > Acked-by: Mikulas Patocka <mpatocka@redhat.com>
>
> 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

\
 
 \ /
  Last update: 2016-04-28 18:01    [W:0.070 / U:3.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site