> even after changing to a power-of-two allocation and starting > with 8k items, aux/acidleak still takes 400mb on a 40mb proc > with only 155278 bytes actually allocated (in the target process). > > is the a chance that pool is not packing the small > allocations together well?
i wouldn't judge pool based on acidleak. have you checked how much data acidleak is allocating in that 400mb? i expect the data array to be huge: it knows about every word in memory that looks vaguely like a pointer. acidleak was never intended to be lightweight. >> if upas/fs is allocating arbitrarily large buffers, >> then its allocation behavior is broken too. > > there are a fixed number of large buffers. up to 15 messages > and mdir uses dirreadall so it can qsort. the qsort is easy enough > to eliminate, but it's more difficult to bound message buffers. i never said fixing it was easy. ;-) russ
