Messages in this thread | | | Date | Fri, 15 Jan 1999 04:13:02 +0100 | From | Marcin Dalecki <> | Subject | Re: SLAB "optimisation" |
| |
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/
| |