Re: [PATCH] slab: introduce kmem_cache_zalloc allocator
From: Andrew Morton
Date: Tue Mar 21 2006 - 05:37:30 EST
Pekka J Enberg <penberg@xxxxxxxxxxxxxx> wrote:
> From: Pekka Enberg <penberg@xxxxxxxxxxxxxx>
> This patch introduces a memory-zeroing variant of kmem_cache_alloc. The
> allocator already exits in XFS and there are potential users for it so
> this patch makes the allocator available for the general public.
> + * kmem_cache_alloc - Allocate an object. The memory is set to zero.
> + * @cache: The cache to allocate from.
> + * @flags: See kmalloc().
> + *
> + * Allocate an object from this cache and set the allocated memory to zero.
> + * The flags are only relevant if the cache has no available objects.
> + */
> +void *kmem_cache_zalloc(struct kmem_cache *cache, gfp_t flags)
> + void *ret = __cache_alloc(cache, flags, __builtin_return_address(0));
> + if (ret)
> + memset(ret, 0, obj_size(cache));
> + return ret;
The way this is supposed to work in slab is that the owner of the cache
provides a constructor which zeroes out newly-allocated storage and the
owner of the cache is supposed to free objects in a constructed (ie:
I've always felt that this was an odd design. Because
a) All that cache-warmth which we get from the constructor's zeroing can
be lost by the time we get around to using an individual object and
b) The object may be cache-cold by the time we free it, and we'll take
cache misses just putting it back into a constructed state for
kmem_cache_free(). And we'll lose that cache warmth by the time we use
this object again.
So from that POV I think (in my simple way) that this is a good patch. But
IIRC, Manfred has reasons why it might not be?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/