On Sun, 8 Jul 2001, Jon Travis wrote: > There is still all this tomfoolery with locking, though, which I think > would be nice to fix with different sized buckets in the freelist. > Stuff that the malloc in glibc does. I cringe at the thought of how > much overhead due to abstraction this whole project is causing.
haha, the abstraction problems started AGES ago :) i think the first real sign of the doom ahead was the argument of changing "ap_pool_t" to "ap_context_t" because there was this arbitrary hash table attached to it. i'd suggest that before any decisions are made regarding global free list or per thread free list someone should study what the non-SMS, pools-only server behaves like. the problems you're looking at now in the SMS server are a result of SMS's "feature" of allocating all the way up through the ancestry adding bytes each step of the way. also -- it would be worthwhile for someone to try a version of pools which keeps no freelist, and uses malloc()/free() on each block. i'm guessing this is faster in a multithreaded server than us doing a per-process global list because malloc() itself already has to deal with multithreading, and has all sorts of other optimisations (i.e. it's not just a first-fit allocator). and as an added bonus it'd be worth trying www.hoard.org's malloc replacement. this would make our code simpler on a multithreaded server, and push the details into libc which presumably the vendor has optimised to go with their threading library. -dean
