Messages in this thread | | | Date | Wed, 21 Dec 2005 08:50:15 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH RT 00/02] SLOB optimizations |
| |
* Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:
> > 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.
i'd suggest to try harder, unless you think the _fundamentals_ of the SLAB allocator are wrong. (which you are entitled to believe, but we also have to admit that the SLAB has been around for many years, and works pretty well)
most of the ugliness in slab.c comes from:
1) debugging. There's no easy solutions here, but it could be improved.
2) bootstrapping. Bootstrapping an allocator in a generic way is hard. E.g. what if cache_cache gets larger than 1 page?
3) cache-footprint tricks and lockless fastpath. SLAB does things all the right way, even that ugly memmove is the right thing. Maybe it could be cleaned up, but the fundamental complexity will likely remain.
Ingo - 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/
| |