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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
