httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: worker mpm: can we optimize away the listener thread?
Date Thu, 29 Nov 2001 18:08:45 GMT
On Thu, Nov 29, 2001 at 09:59:10AM -0800, Ryan Bloom wrote:
> On Thursday 29 November 2001 09:45 am, Brian Pane wrote:
> > Right--the fact that the transaction pools are children of a pool
> > owned by the listener thread means that we have to do locking when
> > we destroy a transaction pool (to avoid race conditions when unregistering
> > it from its parent).
> 
> I'm not sure this will fix the problem, but can't we fix this with one more level
> of indirection?
> 
> Basically, the listener thread would have a pool of pools, one per thread.
> Instead of creating the transaction pool off of the man listener pool, it creates
> the pool of pools off the listener pool, and the transaction pool off the next
> pool in the pool of pools.
> 
>           listener
> 
> sub-pool1	sub-pool2	sub-pool3
> 
> trans-pool	trans-pool	trans-pool
> 
> The sub-pools are long-lived, as long as the listener pool. By moving the
> trans-pool to under the sub-pool, and only allowing one trans-pool off
> each sub-pool at a time, we remove the race-condition, and can remove
> the lock.

That also opens us up for the possibility of pool reuse as well as
cache hit performance. We implement the "pool of pools" as a simple
mutex-protected stack with a set number of pools equal to the number of
threads (or maybe one extra). Then we make sure that the worker clears
and returns the pool before reentering the worker queue. We don't get
the benefit of reusing the most recent thread, which would give us cache
hits on that thread's stack segment, but we do get hits on the pools,
and we even reduce overall memory consumption since the pools that grow
to meet the demand are reused (and we don't force all pools to grow to
meet the peak demand). Interesting.

-aaron

Mime
View raw message