[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dm-devel
Subject:    Re: [dm-devel] [PATCH] md: simplify free_params for kmalloc vs vmalloc fallback
From:       Michal Hocko <mhocko () kernel ! org>
Date:       2016-04-28 16:59:34
Message-ID: 20160428165934.GQ31489 () dhcp22 ! suse ! cz
[Download RAW message or body]

On Thu 28-04-16 11:40:59, Mikulas Patocka wrote:
[...]
> 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.

It is certainly good to address a common pattern by a helper if it makes
to code easier to follo IMHO.

> 
> 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

I have seen this code some time already. I guess it was Al complaining
about it but then I just forgot about it. I have no idea why GFP_ATOMIC
was used there. This predates git times but it should be
https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10/2.6.10-mm1/broken-out/alloc_large_system_hash-numa-interleaving.patch
 The changelog is quite verbose but no mention about this ugliness.

So I do agree that the above should be fixed and a common helper might
be interesting but I am afraid we are getting off topic here.

Thanks!
-- 
Michal Hocko
SUSE Labs

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


[prev in list] [next in list] [prev in thread] [next in thread]