apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: SMS as Pools Patch
Date Wed, 11 Jul 2001 16:14:52 GMT
On Wed, Jul 11, 2001 at 04:53:54PM +0200, Luke Kenneth Casson Leighton wrote:
> how are you going to keep _users_ from _not_ using apr_sms_child_xxx
> and friends?

It's not exported as a function?  Only a SMS itself would see this

> not being funny or anything, but what is a trivial mallocator
> doing adding an extra 4096 bytes in the _first_ place?

Well, part of it is inertia and an optimization.  The current pool 
code adds an additional 4096 bytes to any allocation in order to 
make any allocation of <4096 bytes be done for free since we have
already allocated it - we just tack it on to the block that we have
just allocated.  Dean Gaudet may have more explanation as to why we 
do this, but the current pool code definitely does this.

The completely trivial SMS is tracking.  =)  The names all suck
horrendously, but no one has come up with good names for our SMS.
Trivial SMS is the closest implementation of the current pool 
allocation system.  Tracking is the one you should be able to grasp in
<5 minutes.

I think with a true heap-based memory allocation system we really
don't need this.  However, the SMS code needs to get checked in and 
then we can start to play with other SMS strategies to determine what 
are better options.  

I'd like to see how it performs when MIN_FREE is set to 0.  We'd suck 
at little allocation (actually not - consider that MIN_ALLOC is 4096, 
so if we allocate a bunch of small things in a row, this optimization 
is still present - just that if we allocate >4096 bytes, we don't get 
anything for free).

> that implies that you are second-guessing the parent
> mallocator's ability to manage memory, and maybe
> even screwing _up_ the parent mallocator's ability
> to manage memory!  in fact, that's exactly what's happening!

The problem is that the trivial SMS are stacked on top of each other.
Since we add 4096 bytes to each malloc request, we're kind of screwed.
In the case of a child trivial SMS, we don't want the parent tacking on
more space than possible.

Realistically, though my thought for the long term is to have one root 
trivial SMS (or similar SMS with a freelist) per thread and a bunch of 
tracking SMS (brain-dumb five-minute SMS that don't do much).  I really
think this is where we ought to be headed.  Does that need the
child_malloc path?  Probably not.

> surely there are better ways to do this that can be investigated
> _before_ expanding the SMS API into a more complex system?

We're open to ideas.  =)  The one criticism of SMS so far has been this
behavior with trivial SMS.  Which, isn't really a fault of the SMS
design, just that fact that trivial isn't the greatest strategy.
-- justin

View raw message