Re: [PATCH RT 00/02] SLOB optimizations

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 21 Dec 2005, Pekka J Enberg wrote:
> Hi Ingo,
>
> Steven Rostedt <rostedt@goodmis.org> wrote:
> > > [...] Today's slab system is starting to become like the IDE where
> > > nobody, but a select few sado-masochis, dare to venture in. (I've CC'd
> > > them ;) [...]
>
> On Wed, 21 Dec 2005, Ingo Molnar wrote:
> > while it could possibly be cleaned up a bit, it's one of the
> > best-optimized subsystems Linux has. Most of the "unnecessary
> > complexity" in SLAB is related to a performance or a debugging feature.
> > Many times i have looked at the SLAB code in a disassembler, right next
> > to profile output from some hot workload, and have concluded: 'I couldnt
> > do this any better even with hand-coded assembly'.
> >
> > SLAB-bashing has become somewhat fashionable, but i really challenge
> > everyone to improve the SLAB code first (to make it more modular, easier
> > to read, etc.), before suggesting replacements.
>
> I dropped working on the replacement because I wanted to do just that. I
> sent my patch only because Matt and Steve talked about writing a
> replacement and thought they would be interested to see it.
>
> I am all for gradual improvements but after taking a stab at it, I
> starting to think rewriting would be easier, simply because the slab
> allocator has been clean-up resistant for so long.

And I think that what was done to SLAB is excellent. But like code I've
written, I've often thought, if I rewrote it again, I would do it cleaner
since I learned so much in doing it.

So the only way that I can feel that I can actually improve the current
system, is to write one from scratch (or start with one that is simple)
and try to make it as good as the current system.  But by the time I got
it there, it would be just as complex as it is today.  So only then,  I
could rewrite it to be better, since I learned why things were done the
way they were, and can have that in my mind as I rewrite.  So that means
writing it twice!

Unfortunately, it is probably the case that those that wrote slab.c are
too busy doing other things (or probably just don't want to), to rewite
the slab.c with the prior knowledge of what they wrote.

For the short time, I could just force myself to study the code and play
with it to see what I break, and figure out "Oh, that's whay that was
done!".

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