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 convinced. 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* lukes
