Re: [PATCH] slab: introduce kmem_cache_zalloc allocator

[Pekka J Enberg]

Hi Andrew,

On Tue, 21 Mar 2006, Andrew Morton wrote:
> 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.

Constructors work well for things like lock and and list initialization 
where the object state is naturally in 'initial' state when free'd. They 
don't work well for unconditional zeroing for the exact reasons you 
outline below.

On Tue, 21 Mar 2006, Andrew Morton wrote:
> 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?

I assume the design comes from Bonwick's paper which states that the 
purpose of object constructor is to support one-time initialization of 
objects which we're _not_ doing in this case.

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