To be honest changing sms_trivial to use malloc instead of apr_sms_malloc is an easy move (just a few lines to change) so it's probably worth trying and then seeing what we get...
BTW, I'm impressed by the amount of traffic this has generated. Exactly what I hoped it would do! I guess also I'm wondering if we should apply my patch. For all the reasons given it's not ideal, but it's a starting point, and if in 2 weeks it looks totally different, well, no bother, but at least it lets everyone work on it with a minimum of fuss... Opinions? 3 +1's and I'll commit while I'm in Pheonix (got a nice connection) david ----- Original Message ----- From: "Brian Pane" <[EMAIL PROTECTED]> To: "Sander Striker" <[EMAIL PROTECTED]> Cc: "APR Development List" <dev@apr.apache.org> Sent: Monday, July 09, 2001 1:46 AM Subject: Re: Observations on fragmentation in SMS pools > Sander Striker wrote: > > >I'll think out loud now: > > > Me too :-) > > > > >The solution might be adding specific allocation functions for SMS > >implementations. These functions could look something like this: > > > >APR_DECLARE(void *) apr_sms_child_malloc(apr_sms_t *sms, > > apr_sms_t *child, > > apr_size_t size); > > > >APR_DECLARE(apr_status_t) apr_sms_child_free(apr_sms_t *sms, > > apr_sms_t *child, > > void *mem); > > > >Internally the framework will use the child_malloc_fn if present. If > >not, it will fall back to malloc_fn. > > > >This is something that overthrows the KIS policy though... > > > > I think this approach (or a variant thereof) has a lot of promise. > > One way to look at the root cause of the sms-pool fragmentation > and performance issues is that the notion of "parent pool" implies > two things: > 1. If P is the parent of S, S must cease to exist when > P is destroyed. > 2. If S needs more memory, it gets obtains it from P > by calling the "malloc" method of P. > > It often doesn't make sense for these two roles to be > combined in the same object. Corollary: It doesn't make > sense for apr_sms_malloc(parent) to be the mechanism by > which a child allocates additional space. > > For example, a pool created for a subrequest needs to go out > of scope when its parent does, but it doesn't derive any real > benefit from routing requests for additional blocks through its > parent. We could get better performance if the role of the > parent SMS were to supply a "block source" to the child. This > block souce would be a pointer to an SMS that the child should > call whenever it needed more memory. The block source could be > the parent itself, or it could be any ancestor of the parent. > In the case of a succession of sms_trivials stacked on top of > an sms_std, each sms_trivial would supply the pointer to the sms_std > as the block source for its child(ren). (The resulting setup > would then look like the original pools implementation, in the > sense that children would bypass their parents to get additional > blocks. The difference is that the parent gets to decide what > type of block source its children use--so if a stack of SMSs are > supposed to use memory from a shared memory segment, each SMS > in the stack can ensure that its descendents are using the shared > mem block source rather than some malloc(3)-based block source.) > > Thoughts? > > Thanks, > --Brian > > > >
