lkml.org 
[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.059 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site