apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <jtra...@covalent.net>
Subject Re: Observations on fragmentation in SMS pools
Date Sun, 08 Jul 2001 17:56:59 GMT
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.
> 
> 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.

I talked to rbb about this not too long ago, and he told me that you
did a lot of performance work, and that is why pools use their own
allocation scheme (8k blocks, freelists, etc.) instead of using a
total malloc() oriented scheme.  You are right that libc malloc()
implementations are very fast, can deal with threading issues
more elegantly than we could in APR, and have other niceties 
(different sized buckets, etc.).  There is currently a ton of locking
in the pool implementation to deal with the threads (and we are
actually missing a lock in one needed location, I believe).  

I would love to see some benchmarks on a tuned SMS (for httpd) vs. a 
good, simple, libc malloc().  Especially since other programs using 
APR will not likely be writing their own SMS backend to tweak their
app.

-- Jon


Mime
View raw message