httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: remaining CPU bottlenecks in 2.0
Date Thu, 06 Sep 2001 03:19:50 GMT
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



Mime
View raw message