lkml.org 
[lkml]   [2015]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [HPDD-discuss] [PATCH 2/11] Staging: lustre: fld: Use kzalloc and kfree
Date
>We are hopefully going to get rid of OBD_ALLOC_LARGE() as well, though.
>
>It's simple enough to write a function:
>
>void *obd_zalloc(size_t size)
>{
> if (size > 4 * PAGE_CACHE_SIZE)
> return vzalloc(size);
> else
> return kmalloc(size, GFP_NOFS);
>}
>
>Except, huh? Shouldn't we be using GFP_NOFS for the vzalloc() side?
>There was some discussion of that GFP_NOFS was a bit buggy back in 2010
>(http://marc.info/?l=linux-mm&m=128942194520631&w=4) but the current
>lustre code doesn't try to pass GFP_NOFS.

The version in the upstream client is out of date. The current macro in the Intel master
Branch is:

#define __OBD_VMALLOC_VERBOSE(ptr, cptab, cpt, size) \
do { \
(ptr) = cptab == NULL ? \
__vmalloc(size, GFP_NOFS | __GFP_HIGHMEM | __GFP_ZERO, \
PAGE_KERNEL) : \
cfs_cpt_vzalloc(cptab, cpt, size); \
if (unlikely((ptr) == NULL)) { \
CERROR("vmalloc of '" #ptr "' (%d bytes) failed\n", \
(int)(size)); \
CERROR(LPU64" total bytes allocated by Lustre, %d by LNET\n", \
obd_memory_sum(), atomic_read(&libcfs_kmemory)); \
} else { \
OBD_ALLOC_POST(ptr, size, "vmalloced"); \
} \
} while(0)

>Then it's simple enough to change OBD_FREE_LARGE() to kvfree().
>
>Also it's weird that only the lustre people have thought of this trick
>to allocate big chunks of RAM and no one else has. What would happen if
>we just change vmalloc() so it worked this way for everyone?

Do we really want to encourage vmalloc usages?


\
 
 \ /
  Last update: 2015-05-01 22:41    [W:0.160 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site