apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Re: some reasons why Apache 2.0 threaded is slower than prefork
Date Thu, 08 Mar 2001 22:45:04 GMT
From: "Bill Stoddard" <bill@wstoddard.com>
Sent: Thursday, March 01, 2001 1:26 PM

> http://wstoddard.com/patches/apr_mem_alloc.tar
> This code has some horrible hacks. I was just trying to put something together
> to do some benchmark testing with.
> Here is the idea behind the allocator...
> Define 10 queues (or lists) of free blocks.  There is a list of 32 byte
> blocks, a list of 64 byte blocks, a list of 128 byte blocks, ... up to 8192.
> If you apr_malloc(30), you will pull a block off the 32 byte block list and
> use it. If you need 33 bytes (apr_malloc(33)), you would pull a block off the
> 64 byte block. When you free a block, there is a field in the block header
> telling you which list the block needs to be returned to.  Pretty simple. If
> you play with this, make sure you call apr_mem_init() somewhere early in the
> MPM (or in the apr_init).
> If we were to develop this idea, I would like to add guard bands around each
> block to check for memory overwrites, etc. in debug mode. Enable list size to
> grow and shrink. Now, I malloc 8192 bytes for each list then carve it up into
> pieces and if a list runs out of freeblocks, I revert to malloc/free.  Perhaps
> enable allocating out of shared memory (for process MPMs). Use more efficient
> mechanisms to sync access to the lists.

Just an observation... if you are guard banding it anyways, round the sizes down
by 8 and put four byte magic cookies on either end.

In any case, don't fracture pages too much.  E.g., make sure the boundries stay
on the page, so if we have 12 bytes of block data and 8 guard bytes, you might
start out with 12 byte blocks, then 44, then 108, etc.  This simply assures we
aren't faulting across pages when it can be avoided.  Of course, this implies
our internal magic numbers (like HUGE_STRING_LEN in httpd) should also coincide 
with the allocator.

Good theory, just downloaded the code, I'm looking forward to playing with it
over the weekend.

View raw message