On Sun, Jul 08, 2001 at 10:56:59AM -0700, Jon Travis wrote: > On Sun, Jul 08, 2001 at 10:41:12AM -0700, dean gaudet wrote:
> > 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. this _can_ be mitigated by doing your own memory-management on top of a more normal one. which is what sander's 'smart memory allocator' does. sma is targetted at having to have massive amounts of reallocs and mallocs and then freeing large numbers of them in one blast, repeat. luke
