Re: [RFC] Slab allocators: Drop support for destructors

[William Lee Irwin III <wli@holomorphy.com>]

On Thu, May 10, 2007 at 12:00:08PM -0700, Christoph Lameter wrote:
> As far as I can tell there is only a single slab destructor left (there 
> is currently another in i386 but its going to go as soon as Andi merges 
> i386s support for quicklists).
> I wonder how difficult it would be to remove it? If we have no need for 
> destructors anymore then maybe we could remove destructor support from the 
> slab allocators? There is no point in checking for destructor uses in 
> the slab allocators if there are none.
> Or are there valid reason to keep them around? It seems they were mainly 
> used for list management which required them to take a spinlock. Taking a 
> spinlock in a destructor is a bit risky since the slab allocators may run 
> the destructors anytime they decide a slab is no longer needed.
> Or do we want to continue support destructors? If so why?

It used to be that some caches retained attached allocated objects
until the time of a destructor call, at which time they were freed.
I'm not aware of any current use of this idiom. Space consumption
pathologies arise very easily from the use of this idiom, so it's
not clear to me it's worth supporting.

List membership of cached preconstructed objects is part of a more
general idiom of updating such objects at the time of a state change
requiring the preconstructed state to change. It is possible to support
this without a ->dtor() operation by means of the allocator supporting
a flushing operation to dispose of cached preconstructed objects, or
the allocator supporting a generation marker for such state changes so
that stale preconstructed objects are tagged as such and re-constructed
on-demand.

The last idiom I can recall for which ->dtor() operations make sense is
essentially an integrity check. It's possible to support this with an
explicit slab debugging option to verify that freed objects have been
returned to their preconstructed states with superior error reporting
provided that some method of comparing the states is arranged. I'm not
aware of any in-kernel uses of this idiom.

Others may be aware of other idioms ->dtor() operations are used to
implement.


-- wli
-
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/