Hi,
For the last few months, I've been working (on and off) on a replacement
for my implementation of the Slab allocator.
The new allocator has the features;
o Designed with SMP in mind.
The allocator has "clips", which are per-cpu lists of objects
without locks.
To allow support for large clips and good slab reaping, the
objects in the clips can be unloaded back into their slabs.
o Support for different types of memory.
Previously, DMA support was a "kludge"!
The new design supports subcaches. Each cache has subcaches
for the type of memory it supports. Currently, only two types
of memory are supported; NORMAL and DMA.
A better name might be zone-caches - matching the 2.4.x
page types.
o Better object packing.
Yet another object packing method has been added. This can
increase the number of objects per slab with on-slab bufctls.
All with reduced branching on the allocation/release paths!
o Page allocator friendly.
Always tries to use zero-order page sized slabs, even if it
causes memory to be wasted. A bit of waste is better than
order-1 page allocations!
o Ability to destroy caches cleanly.
Well, it will be "clean" when I finish it off and tidy the code
up. The "cleaniess" refers to not having to continiously hold a
lock to prevent a cache being destroyed (removing scalability
bottlenecks on SMP).
This will probably panic/lockup your machine at the moment.
o Ability to add new general size caches on the fly.
This is coded, but never tested. Again, will probably cause a
panic/lockup.
To avoid having to lock the general cache linkage for SMP
(searched from a kmalloc(), so a lock would be bad), some
"tricks" are pulled.
o Cleaner code.
It will be - eventually.
For now, some comments are correct, some aren't, and some are
missing.
o Some more stuff.
At present, the code is for 2.2.15 only and is pre-alpha quality.
I might decide to re-design it tomorrow if I think of something better.
I will soon be moving to 2.4.x - infact, I will need to when finalising
this. The page structures aren't cached aligned in 2.2.x, so the slab's
internal usage of this structs' members may well cross L1 cache lines (not
good for performance).
This code has only been run on an UP box.
I don't have access to an MP box, but hope to by next weekend. Note;
the MP code uses different methods to add general size caches, and to
empty clips - none of which can be easily tested on UP (even running an
MP kernel on UP doesn't help much). MP owners, bewarned.
A patch is available at;
http://www.nextd.demon.co.uk/slab.01.patch
Or to just view the allocator's source;
http://www.nextd.demon.co.uk/slab.c
http://www.nextd.demon.co.uk/slab.h
Hopefully, I've loaded up the latest version. :(
Mark
-
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/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:23 EST