More on malloc stuff

[Jim Jagielski <ji...@jaguNET.com>]

What I'd like to work on is kinda represented by the below from
alloc.c:

 min_size += BLOCK_MINFREE;
 blok = malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC);

IMO malloc_block should only do malloc's of some integer number of
the natural pagesize for the machine in question. As Dean says,
it can make a difference performance-wise if the block is aligned
on it's natural border.
-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
            "Look at me! I'm wearing a cardboard belt!"

Re: More on malloc stuff

[Dean Gaudet <dg...@arctic.org>]

On Sat, 27 Dec 1997, Marc Slemko wrote:

> Are you sure that making it read-only (are you thinking of mprotect 
> or what?) will help Solaris?  I thought that it still reserved
> for such regions, but that could just be my faulty memory.

You actually have to mmap() it a special way and then mprotect() that if I
remember correctly.  You can't do it with just malloc/mprotect.  I could
easily be wrong though. 

Dean

Re: More on malloc stuff

[Marc Slemko <ma...@worldgate.com>]

On Sat, 27 Dec 1997, Dean Gaudet wrote:

> There's more to it than just changing that though ... because we don't
> control all the malloc's that happen we need to malloc (N+1)*page_size - 1
> bytes when we really want N*page_size bytes, and we have to round up to
> the nearest page size to align the allocation.  So we essentially end up
> wasting memory if we do it for each call to malloc_block. 
> 
> Instead what I was proposing was to do a large malloc early on for some
> number N pages, and then carve up that malloc into blocks as required. 
> Then later do another malloc and so on.
> 
> I'm not sure if it's a win without doing some of the other things I
> mentioned... like protecting memory as read-only after config time so that
> on solaris it has better fork behaviour.

Are you sure that making it read-only (are you thinking of mprotect 
or what?) will help Solaris?  I thought that it still reserved
for such regions, but that could just be my faulty memory.

I wish I could convince my University to grab the source; wouldn't
cost them anything...

Re: More on malloc stuff

[Dean Gaudet <dg...@arctic.org>]

There's more to it than just changing that though ... because we don't
control all the malloc's that happen we need to malloc (N+1)*page_size - 1
bytes when we really want N*page_size bytes, and we have to round up to
the nearest page size to align the allocation.  So we essentially end up
wasting memory if we do it for each call to malloc_block. 

Instead what I was proposing was to do a large malloc early on for some
number N pages, and then carve up that malloc into blocks as required. 
Then later do another malloc and so on.

I'm not sure if it's a win without doing some of the other things I
mentioned... like protecting memory as read-only after config time so that
on solaris it has better fork behaviour.

There's also the DATA and BSS stuff to think about:

% size httpd
text    data    bss     dec     hex     filename
229204  71624   27340   328168  501e8   httpd

(that's from HEAD with almost all modules compiled in)

The DATA is mostly read-only (57840 bytes are in the .rodata section) --
there's more that could be read-only, like if all the module structures
were marked const, any string pointers within them also marked const,
and the pointers to the command_rec's marked const, and the string
pointers in those... and os on.

For bss that's potentially 27340 bytes that has to be copied into each
child.   Most of that is in the core -- server_confname, coredump_dir,
server_root are all 8k a piece... which shouldn't need to be copied into
each child, but solaris will reserve room for all of them.  they could
probably get away with being defined as MAXPATH or whatever that
constant is.  There's a bit of a chicken-egg problem with bss because
you need some to set up http_main.c and alloc.c, but I bet we could get
away with less than 4k of bss.

I dunno how much a win doing all of this is... I'd guess that solaris
is the platform to test on because it's the one where people complain
the most about the swap consumed by httpds.  It probably shows up on
others though.

Dean

On Sat, 27 Dec 1997, Jim Jagielski wrote:

> What I'd like to work on is kinda represented by the below from
> alloc.c:
> 
>  min_size += BLOCK_MINFREE;
>  blok = malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC);
> 
> IMO malloc_block should only do malloc's of some integer number of
> the natural pagesize for the machine in question. As Dean says,
> it can make a difference performance-wise if the block is aligned
> on it's natural border.
> -- 
> ====================================================================
>       Jim Jagielski            |       jaguNET Access Services
>      jim@jaguNET.com           |       http://www.jaguNET.com/
>             "Look at me! I'm wearing a cardboard belt!"
>