apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: SMS as Pools Patch
Date Thu, 12 Jul 2001 09:20:59 GMT
[...]
>>> we _know_ that malloc and free are pretty efficient on
>>> most operating systems.  so why not rely on that
>>> efficiency instead of trying to second-guess it and
>>> round-up the malloc-block sizes?
>> 
>> Because we most definitely get a significant speedup by 
>> allocating more mem than the user asks for, so we can serve
>> the next request from our own block. 
> 
> okay... urr...  so... again, you're second-guessing the
> capabilities of the parent-mallocator (in this case,
> malloc, via the default-sms.
> 
> or, is the parent-mallocator another apr_[misnamed:)_trivial?

It is another trivial. Oh, wait, you definitely need to take
a look at apr/memory/unix/apr_sms_trivial.c. Justin added some
comments so it should be a bit more clear what is happening at
the moment than without the comments :)
 
> because if it's an apr_sms_trivial, then your speedup is
> _actually_ achieved by avoiding problems in another part of,
> or the usage of, apr_sms_trivial.

It is probably the usage of. Also, problems can be avoided by
using apr_sms_trivial_create_ex() which allows you to set
min_free, min_alloc and max_free at runtime.
 
> > In case of the patch we get a stack where "trivial" is the
> > child of another "trivial". We now have the child sms asking
> > for mem for the parent, which adds the 4k bytes etc.
> > We can circumvent this behaviour by doing the
> > apr_sms_child_malloc and friends implementation. 
> 
> this really does sound to me like there is a problem
> with stacking a trivial on top of a trivial, and that
> the proposed solution is to make this a special case
> to deal with what is effectively a broken situation.

Yes, this could very well be. What stings me though is that
stacking trivials is giving such a penalty. So basically,
what I am trying to say is that the apr_sms_child_xxx
functions make it possible to stack (2 of the same, or
2 smss that make assumptions about allocations) on top
of eachother, without adding extra bytes for example.
 
>> [...]
>>> surely there are better ways to do this that can be investigated
>>> _before_ expanding the SMS API into a more complex system?
>> 
>> Maybe... :)
>> But that involves changes to the httpd codebase which is not an
>> option with both pools and pools == sms should work. It will be
>> numerous #ifdefs in the httpd code (at the location of every
>> apr_pool_create) if we go down that road.
> 
> .... how about a #define that makes apr_pool_create call a
> new function that does what you need, especially if what
> you need is the same in every place [exactly what, you haven't
> explained, so i don't know :) ]

We have that now. The first sms created is a std sms. All the others
become trivial smss. Justin is doing some testing to see if we
can do a trimix of std, trivial and tracking. In the long run it means
that we are having to replace the apr_pool_create calls in httpd
with the actual apr_sms_xxx_create call of the type of sms we need.

> sorry to be so stick-in-the-mud, my friend, esp. on-list.
> it's important to me that there are good reasons for things :)

No prob :)
Points well taken.

Sander

Mime
View raw message