> but removing ctor/dtor is i think a mistake, although i agree that it's
> inactive code currently.
>
> > I bet that 100% of the benefit of slab could be gotten with a really small
> > skb "cache" in front of a much simpler kmalloc() (where the skb cache
> > would be a few entries worth of pre-initialized skb's). Or alternatively
> > just keep sab, but separate the notion of allocation and caching - so that
> > the 99% that are _not_ interested in constructors would never have to go
> > through any parts that know about them.
>
> the SLAB also keeps caches separated, which (to me) feels better than what
> kmalloc could give us anytime. I was always worried about the multipage
> allocations done by the SLAB, but this fragmentation issue seems to be a
> red herring after all.
This isn't true. Do you remember the discussion after it got
introduced? There where *plenty* of people crying about exactly this
problem.
> another example of constructable slab objects is the dcache, we could
> construct them this way:
>
> (not all uses of slab are perinitializable, eg. vmas are usually 'cloned'
> from already existing vmas, but even in this case there are fields that
> are almost never used, eg. we could initialize vma->vm_pte to 0 when the
> vma is deallocated)
Ah there you repeat my main argument why the whole idea behind it
doesn't
buy you much in linux.
You had TWO YEARS of time to proove it in PRACTICE that it
would be usefull and how wonderfull it would perform.
However for whichever reasons -- nobody did! Maybe this isn't
just accident?
--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/