apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: [PATCH] Maximum free memory in an allocator OR: hifree, revisited
Date Wed, 10 Apr 2002 15:03:21 GMT
On Wed, Apr 10, 2002 at 02:47:26PM +0200, Branko ?ibej wrote:
> >I know Ian wants this badly.  I can go either way.
> >I would really like to see some perf comparisons with
> >and without it to see if it doesn't do too much damage
> >to performance (or if it does at all in a measurable fashion).
> >
> >Sander
> >
> 
> +1
> 
> I think a small performance penalty is better than keeping unused 
> allocated VM around.

Actually pools trade processing time for memory space. Pools allow us to
malloc larger chunks of memory (to reduce freelist management overhead)
and then to delay the costs of freeing until we want to "checkpoint"
the memory.

However, the hi-free idea may be useful to counteract extreme cases where
a single thread may have consumed an abnormally high amount of memory. I
can see us using the hi-free setting somewhere significantly higher than
a "normal" requests's memory usage, just to catch those stray requests
that take 10x normal.

Like Sander said, we need to test this for performance implications.

-aaron

Mime
View raw message