httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Harris" <dhar...@drh.net>
Subject RE: [patch] smarter free block allocation to fix leak
Date Thu, 05 Aug 1999 18:57:19 GMT

Dean Gaudet wrote:
> Nice debugging... although I disagree with the solution.
>
> best-fit is generally worse than first-fit when it comes to allocators,
> but that's with allocators that have somewhat more random memory access
> patterns than ours, so i'm not sure it applies.  I just generally don't
> want to have to scan the whole free list.
>
> I'm not sure it makes sense for us to keep blocks on the free list which
> are greater than BLOCK_MINALLOC in size... maybe we should just free()
> them.  That way we get the benefit of whatever the underlying malloc()
> does with large blocks -- which on some unixes will actually munmap() them
> and return storage to the system.
>
> Or maybe we need a BLOCK_MINKEEP, which is something like 32768?

Here's a list of the size of blocks allocated verses number of blocks allocated
with that size in a Apache+mod_ssl where it parsed configuration (1k virtual
hosts) and then served a few connections for static files and some directory
indexes. This lists the counts blocks allocated in the parent and in the
children.

      SIZE     NUMBER
      8192       1258
      8200       2001
     12288          4
     20480          2
     36864          2
     69632          2
    135168          2
    266240          2
    528384          2
   1052672          2
   2101248          2
   4198400          2

The blocks of size 8192 are created by small requests (such as 4k) getting
rounded up to BLOCK_MINALLOC and the blocks of 8200 bytes come from where I
don't know. First, it seems that it would be smart to set BLOCK_MINALLOC to
8200 so that those blocks are the same size. (I can't track down where the 8200
byte blocks are coming from, because my gdb is not working anymore... rrrrr)

If one wants to implement hashing, I propose breaking block_freelist down into
these three lists:

block_freelist_min     x <= BLOCK_MINALLOC
block_freelist_small   BLOCK_MINALLOC < x <= BLOCK_MINALLOC*2
block_freelist_big     BLOCK_MINALLOC*2 < x

And doing a best fit search inside each of those lists.

I agree with Dean that the memory allocation in Apache is probably a bit more
deterministic than most malloc operations, so I'd like to be able to have some
sort of best fit searching going on.

This can be optionally combined with a BLOCK_MINKEEP.

Thoughts?

 - David Harris
   Principal Engineer, DRH Internet Services



Mime
View raw message