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 function? > 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
