Linus Torvalds wrote:
>
> On Wed, 13 Jan 1999, MOLNAR Ingo wrote:
> >
> > On Wed, 13 Jan 1999, Marcin Dalecki wrote:
> >
> > > Or put it again into 2.3 or whatever. [...]
> >
> > it breaks the interface. The SLAB allocator should not be faulted for
> > other code not using it's capabilities ... It's not something obsolete,
> > it's a future use ...
>
> The slab code _should_ be faulted for being ugly as hell, and much too
> complex for it's uses. I've wanted to remove it several times completely,
> going back to the older kmalloc(). I appreciate people looking into
> removing features that are hardly ever used and of dubious value.
No need to say that if only my english where better I couldn't express
it
better by myself.
> 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.
OK Linus if you give the blessing I will spend much more
ime on making this somehow more smooth. The separation idea
is something certainly worth a second tought. Maybe one could
provide a real clean abstraction for the free list mechanism used
all around the kernel thus helping reducing code duplication.
I hope I have already shown by practice that optimizing is
something I appreciate doing
(remember the complete CD-ROM driver in just about two pages :-).
I have already some ideas about how to first gather real allocator
behaviour from the kernel, and how to move the developement of the slab
code into user space with easy proper bechmarking, based on this *real*
data, using all the usual user space tools to tweak it to no end...
However since I'm already proffesional at coding, I wouldn't like
to spend serious time on this without knowing first, that the results
will have some real chances to be actually used.
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/