On Wed, 11 Jul 2001, Justin Erenkrantz wrote: > 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.
nope you've pretty much summed it up. it is a questionable optimisation though. > 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). i think after i ironed out a few quirks i didn't bother playing with MIN_FREE (which was there before i started playing with the allocator)... even though it seemed somewhat damaging because of the odd sized blocks it started to create on the freelist. it's probably best to have MIN_FREE 0. -dean
