Re: [PATCH] slab: introduce kmem_cache_zalloc allocator

[Andrew Morton <akpm@osdl.org>]

Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:
>
> From: Pekka Enberg <penberg@cs.helsinki.fi>
> 
> 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.
> 

hmm.

> + * 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;
> +}
> +EXPORT_SYMBOL(kmem_cache_zalloc);

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:
zeroed) state.

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?