Why do pools even have a separate "active" block vs a list of old
"inactive blocks"? Especially now if we're going to start reusing
some of the inactive blocks anyway...
What about this:
- When palloc() requests some mem, see if there's any block with
enough unused room to handle it. If so, allocate in that block.
Else, find or malloc a new block that is at least large enough to
hold the request, maybe doubling it against future allocations.
It may or may not be worthwhile to store the blocks sorted by
available unused space.
- When a pool is cleared/destroyed, walk its blocks marking
everything as unused. If that leaves a huge amount of unused
room (more than BLAH bytes), then free() some or all of it,
otherwise just give it back to the top level unused-block list.
This way, a pool just has a list of blocks. None is any more active
than another, and there's no special case, just normal code flow.
I'm aware that this is a loose description, but hope it's enough to
give the gist of the idea.
Apologies if all this has been gone over before. I didn't participate
in the original pool design discussions; I'm just basing these
comments on the way it seems to work today + the proposed changes.
-Karl
"Sander Striker" <striker@apache.org> writes:
> > 1. Keep each pool's list of 'old' active blocks sorted by size. If
> > a request comes in that won't fit in the current active block,
> > then try to alloc the request in the largest 'old' active block
> > (instead of alloc'ing a completely new active block).
> > Effectively, we get some memory re-use now.
> >
> > 2. When a pool is destroyed or cleared, normally all of its
> > inactive blocks are given back to a 'global free list' in the
> > pool hierarchy. We now have a threshold size that can be set:
> > if the global-free-list ever grows larger than the threshold,
> > then the 'extra' inactive blocks are actually free()d. We've
> > set the maximum free-list size at 4M for now.
> >
> > Anyway, I've included the patches below for people to look at.
> > Apparently Sander posted these before, but nobody had a reason to
> > care. Well, now Subversion *really* needs these features.
>
> Well, I need to clarify that the high free patch has come up before
> and a small group of people wanted it included (ianh and brianp iirc).
> I didn't commit it since the demand was too low and I was +0 myself.
> Seeing the impact it has on subversion and the fact that the developer
> has control over the threshold (which defaults to unlimited, so no
> surprises there), I've decided to go ahead and commit this change
> within a day or two unless major objections are raised.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 22 21:32:45 2002