RE: [PATCH] Maximum free memory in an allocator OR: hifree, revisited

[Sander Striker <st...@apache.org>]

Hi,

Just raising this again.  This time I'll ask differently:
Is anyone opposed to adding this? [feedback please]

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


> From: Sander Striker [mailto:striker@apache.org]
> Sent: 21 March 2002 09:13

> > From: Bill Stoddard [mailto:bill@wstoddard.com]
> > Sent: 19 March 2002 21:36
> 
> > This could be quite useful for mod_*_cache.  What triggers the free?
> 
> The free is triggered on either apr_pool_clear or apr_pool_destroy,
> when the blocks in the pool are returned to the allocator (using
> apr_allocator_free()).  When adding a block to the freelist causes
> the freelist to be larger than then threshold (set with 
> apr_allocator_set_max_free()), the block will be free()d instead
> of added.
> 
> The default is to have max_free be 0, which translates to unlimited,
> which is the current behaviour.
> 
> Ofcourse this patch will come at a small performance penalty, but
> I'm not sure if it is measurable.
>  
> > Bill
> 
> Sander
> 
> > ----- Original Message ----- 
> > From: "Sander Striker" <st...@apache.org>
> > To: <de...@apr.apache.org>
> > Sent: Tuesday, March 19, 2002 2:45 PM
> > Subject: [PATCH] Maximum free memory in an allocator OR: hifree, revisited
> > 
> > 
> > > Hi,
> > > 
> > > Keep getting the question if the hifree patch is
> > > going in.  So, decided to revisit that patch and
> > > implement it now we have the allocators.
> > > 
> > > For those who didn't follow that thread:
> > > This patch allows the programmer to set a maximum
> > > amount of free bytes allowed on the allocators
> > > freelist.  Anything over it will be free()d back
> > > to the system.
> > > 
> > > Thoughts?
> > > 
> > > Sander
> 

Re: [PATCH] Maximum free memory in an allocator OR: hifree, revisited

[Aaron Bannert <aa...@clove.org>]

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

Re: [PATCH] Maximum free memory in an allocator OR: hifree, revisited

[Branko Čibej <br...@xbc.nu>]

Sander Striker wrote:

>Hi,
>
>Just raising this again.  This time I'll ask differently:
>Is anyone opposed to adding this? [feedback please]
>
>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.

>
>
>
>>From: Sander Striker [mailto:striker@apache.org]
>>Sent: 21 March 2002 09:13
>>
>
>>>From: Bill Stoddard [mailto:bill@wstoddard.com]
>>>Sent: 19 March 2002 21:36
>>>
>>>This could be quite useful for mod_*_cache.  What triggers the free?
>>>
>>The free is triggered on either apr_pool_clear or apr_pool_destroy,
>>when the blocks in the pool are returned to the allocator (using
>>apr_allocator_free()).  When adding a block to the freelist causes
>>the freelist to be larger than then threshold (set with 
>>apr_allocator_set_max_free()), the block will be free()d instead
>>of added.
>>
>>The default is to have max_free be 0, which translates to unlimited,
>>which is the current behaviour.
>>
>>Ofcourse this patch will come at a small performance penalty, but
>>I'm not sure if it is measurable.
>> 
>>
>>>Bill
>>>
>>Sander
>>
>>>----- Original Message ----- 
>>>From: "Sander Striker" <st...@apache.org>
>>>To: <de...@apr.apache.org>
>>>Sent: Tuesday, March 19, 2002 2:45 PM
>>>Subject: [PATCH] Maximum free memory in an allocator OR: hifree, revisited
>>>
>>>
>>>>Hi,
>>>>
>>>>Keep getting the question if the hifree patch is
>>>>going in.  So, decided to revisit that patch and
>>>>implement it now we have the allocators.
>>>>
>>>>For those who didn't follow that thread:
>>>>This patch allows the programmer to set a maximum
>>>>amount of free bytes allowed on the allocators
>>>>freelist.  Anything over it will be free()d back
>>>>to the system.
>>>>
>>>>Thoughts?
>>>>
>>>>Sander
>>>>
>


-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/

Re: [PATCH] Maximum free memory in an allocator OR: hifree, revisited

[Justin Erenkrantz <je...@apache.org>]

On Wed, Apr 10, 2002 at 12:17:58PM +0200, Sander Striker wrote:
> Hi,
> 
> Just raising this again.  This time I'll ask differently:
> Is anyone opposed to adding this? [feedback please]

Can you please repost the patch?  -- justin