apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject Re: Observations on fragmentation in SMS pools
Date Sun, 08 Jul 2001 17:41:12 GMT
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


Mime
View raw message