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