* Pekka J Enberg <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
