Re: SLAB "optimisation"

Marcin Dalecki (dalecki@cs.net.pl)
Fri, 15 Jan 1999 04:13:02 +0100

Regis Duchesne wrote:
>
> Mingo wrote:
> > Unless i'm missing something in the slab
> > code, the existance of ctor/dtor does not affect typical
> > allocation/deallocation at all, they are only invoked when the cache grows
> > or shrinks.
>
> > i agree that slab.c is not readable.
> Agreed. And I like patches whose purpose is to "clean-up", Marcin. But
> removing already implemented features, even if they are not (yet) used
> a lot, is another thing.
>
> > but removing ctor/dtor is i think a mistake, although i agree that it's
> > inactive code currently.
> Yes and yes.
>
> If you read again "The Slab Allocator: An Object-Caching Kernel Memory
> Allocator" by Jeff Bonwick (Sun Microsystems), it states:
>
> "The cost of constructing an object can be significantly higher than
> the cost of allocating memory for it" (look at the figures provided)

There is some other conceptual problem with the slab ctor/dtor design
about in addition to the object cloning case,
which the bonwick paper doesn't tell you anything about:
predictability of execution time... Same like with any general garbage
collection. Any ideas how to threat this!?

--Marcin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/