this is the wrong way to fix this problem.
i can't imagine any reason why creating a pool should be slow --
rather than band-aid around it, i think it'd be better to find out that
problem first. it should be as simple as a couple pointer operations.
freelists are a feature of modern memory allocators -- including per-cpu
optimisations. the right fix is probably to start relying on libc more.
(see apr-dev threads a few months ago where i was advocating getting rid
of apr freelists entirely.)
fwiw -- freelist implementations are almost always better off LIFO rather
than FIFO. basically the most recently freed object is more likely to be
mapped in the TLB and have valid cache lines. older objects will incur
TLB and cache misses.
you can take these comments as a veto, but i know the patch has been
committed already.
-dean
On Mon, 27 Aug 2001, Aaron Bannert wrote:
> This patch implements a resource pool of context pools -- a queue of
> available pools that the listener thread can pull from when accepting
> a request. The worker thread that picks up that request then uses
> that pool for the lifetime of that transaction, clear()ing the pool
> and releasing it back to what I'm calling the "pool_queue" (har har).
> This replaces the prior implementation that would create and destroy
> a transaction pool for each and every request.
>
> I'm seeing a small performance improvement with this patch, but I suspect
> the fd_queue code could be improved for better parallelism. I also
> suspect that with better testing this algorithm may prove more scalable.
>
> -aaron
