Messages in this thread | | | Date | Tue, 21 Mar 2006 13:03:25 +0200 (EET) | From | Pekka J Enberg <> | Subject | Re: [PATCH] slab: introduce kmem_cache_zalloc allocator |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |