[lkml]   [2005]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RT 00/02] SLOB optimizations

    On Wed, 21 Dec 2005, Ingo Molnar wrote:
    > * Steven Rostedt <> 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 ;) [...]
    > 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'.

    Exactly my point! The complexity of SLAB keeps it at the "I could not do
    it better myself" catagory. This wasn't suppose to be a bash, it was
    actually a complement. But things in the "I could not do it better
    myself" catagory are usually very hard to modify. Because, unless you are
    at the level of genius of those that wrote it, you may easily break it.
    Or put it to a level of "Ha, I can do this better".

    > 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 perfectly agree with this statement. As I mentioned earlier, it may
    have been different if I was a part of the changes that were made. But I
    wasn't, and that leaves me the task to figure out why things were done the
    way they were done. Before changes can be made, one must have a full
    understanding of why things exist as it does.

    Don't get me wrong, my comments are more of a frustration with myself that
    I'm having trouble understanding all that's in SLAB. I understand the
    SLAB concept, but I'm having trouble with understanding the current
    implementation. That's _my_ problem. But I will continue to work at it,
    and maybe I will be able to produce some clean up patches once I do

    > the SLOB is nice because it gives us a simple option at the other end of
    > the complexity spectrum. The SLOB should remain there. (but it certainly
    > makes sense to make it faster, within certain limits, so i'm not
    > opposing your SLOB patches per se.)

    I like the SLOB code, because it was simple enough for my mortal mind. I
    actually started to play with it to get a better understanding of the way
    the SLAB works. It has actually helped in that catagory.

    -- Steve

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-21 14:10    [W:0.022 / U:7.864 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site