apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: SMS as Pools Patch
Date Thu, 12 Jul 2001 09:38:11 GMT
On Thu, Jul 12, 2001 at 11:20:59AM +0200, Sander Striker wrote:
> [...]
> >>> 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 :)
ack.  cvs update and comments to follow...

> > 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.

ah ha :)

> > > 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.

... intuitively, i can only say that i'm not entirely

which means that i feel that, given the current information
i know of, i can perceive a simpler and more structured
solution.  but as usual, i am having difficulty sieving
it through my cross-wired brain into actual... like...
concepts, y'know.  [i'll cut with the zen, now]

> >> [...]
> >>> 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.
that is what i would expect to have to happen _anyway_ -
due to the other discussion-threads about considerations of doing one
pool per thread, blah blah _even_ if sms is not used.

same area, _probably_ the same problem :) :)

> > 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.

*silly grin*


View raw message