Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 08 Jul 2001 19:56:11 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: Observations on fragmentation in SMS pools
To: dev@apr.apache.org
Message-id: <3B491D4B.4030006@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
References: <JLEGKKNELMHCJPNMOKHOIEJGECAA.striker@apache.org>

Sander Striker wrote:

>>To be honest changing sms_trivial to use malloc instead of 
>>apr_sms_malloc is
>>an easy move (just a few lines to change) so it's probably worth 
>>trying and then seeing what we get...
>>
>
>Massive leakage :)
>
>Remember how the apr_sms_reset code works; it does not have to
>traverse and destroy all children since they all use the memory
>from that sms.
>
I propose that it's better to not optimize for reset.

With all the fragmentation I'm seeing in the httpd, the
number of blocks managed by an SMS in the middle of a stack
can be larger than the number of blocks that its descendants
would have to manage (and free upon destruction) if they
got memory from a block source themselves.  Thus we'd likely
have _less_ work to do upon reset if the SMS being reclaimed
had to recurse through its descendants and ask them to return
their blocks by themselves (because the total number of blocks
being returned to SMSs further down the stack would be smaller).

This problem would go away, of course, if the memory management
strategy employed by the parent SMS were one that didn't cause
so much fragmentation.  But I don't see a way to accomplish
that without slowing down allocation.

--Brian