Hi Dormando, That works for my use case and that is how I was planning on doing it, so thanks for the feedback, always nice to hear from people who know the code that the overall concept is not way off base
- jak On Oct 26, 6:17 pm, dormando <[email protected]> wrote: > > > 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? > > If you change the slabs_init routine to presize your exact slab classes, > that'll work. Keep in mind that the slab allocator doesn't handle > re-allocating memory across slabs. Once memory is given to a slab class, > that's it.
