> Don't know of anyone offhand... The code related to the slabber isn't too > complex, so you'd get an idea from a read-through.
Yeah, that is why I think this idea may work, tweak something very simple, yet very well tested. > slabs.c just defines what sizes memory is, what to hand out where, etc. > Managing it outside of > that (hash table, lru, etc) is up to your application. Right, that is what I want, my app will do its own eviction. > It still has a weakness of not being able to reassign memory if you put it > all into one slab class pool. I have 16 fixed sizes (ranging from 1K-6K, all slightly irregular size [e.g. 1028 bytes]), so I will use the slab allocator every time I need one of these fixed sizes. So I will have 16 different slab-classes (unsure of terminology) and there may be minimal overhead (possibly 1MB per slab-class that is underunused) but I can live w/ that. Are my assumptions correct? and thanks, jak
