httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject Re: remaining CPU bottlenecks in 2.0
Date Thu, 06 Sep 2001 03:34:30 GMT
I got 1 more question about the solaris implementation
of the Threaded/Worker MPM.

should we be called the setconcurrency flag on startup ?
I know solaris figures it out along the way, but a bit of gentle
prodding never hurt.

Brian Pane wrote:

> Justin Erenkrantz wrote:
> [...]
>>> * The discussion here covers only CPU utilization.  There are other
>>>  aspects of performance, like multiprocessor scalability, that
>>>  are independent of this data.
>> Once we get the syscalls optimized (I'm reminded of Dean's attack
>> on our number of syscalls in 1.3 - I believe he went through syscall
>> by syscall trying to eliminate all of the unnecessary ones), I think 
>> the next performance point will be MP scalability (see below for
>> lock scalability on solaris).  But, we do need to see what we can do 
>> about optimizing the syscalls though...
> The syscall profile for 2.0 looks close to optimal (as long as you
> disable .htaccess files and symlink checking).  We're doing a few
> too many gettimeofday calls per request, though; I 'll investigate
> whether any of these can be optimized away.  (Fortunately, gettimeofday
> is cheap compared to time(2).)
> [...]
>>> * _lwp_mutex_unlock() gets from pthread_mutex_unlock(),
>>>  but only from a small fraction of pthread_mutex_unlock calls
>>>  (Can someone familiar with Solaris threading internals explain
>>>  this one?)
>> The LWP scheduler may also call _lwp_mutex_unlock() implicitly -
>> LWP scheduler is a user-space library so it gets thrown in
>> with our numbers I bet.
>> Here's some background on Solaris's implementation that I
>> think may provide some useful information as to how the locks will 
>> perform overall.  (If you spot any inconsistencies, it is
>> probably my fault...I'm going to try to explain this as best as
>> I can...)
>> First off, Solaris has adaptive locks.  Depending if the owner of the 
>> lock is currently active, it will spin.  If the system sees
>> that the owner of the held lock is not currently active, it will
>> sleep (they call this an adaptive lock - it now enters a turnstile).
> Ah, I guess that explains why only a small fraction of pthread_mutex_lock
> calls on Solaris seem to result in calls to lwp_mutex_lock: in the fast
> case where the lock is available, it just stays in user-mode code?
> --Brian

View raw message