On Sat, Apr 27, 2002 at 07:39:24PM -0700, Brian Pane wrote: > I was going to complain about the addition of yet another mutex > to the critical path of request processing, but it got me thinking > about an approach to making worker faster: shorten the time spent > in the mutex-protected region.
Yes! The other neat thing about this is we get to balance the critical path between two mutex regions, rather than one_big_mutex. > By shortening the code path between the lock and the unlock, we > can reduce the probability that two or more threads will be > contending for the mutex at once. And uncontended mutexes have > a lot less overhead. > > I'm going to experiment with streamlining the code within the > mutex-protected blocks of the fdqueue functions to see how much > it helps the multiprocessor performance. At first glance, the > candidates for optimization are: > * In the case where we can't recycle a pool in ap_queue_pop(), > move the destruction of the pool *outside* the mutex-protected > block. > * Maybe change the queue size to a power of two so that we can > replace the modulo operations with a bit mask. ++1 on both accounts. I was also thinking that we could make the queue elements simple pointers, rather than 2 elements in a structure. That way the element lookups can happen outside of the mutex region, and inside we can have a simple struct* assignment. -aaron
