>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?
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
