httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: remaining CPU bottlenecks in 2.0
Date Thu, 06 Sep 2001 16:28:46 GMT
On Wed, Sep 05, 2001 at 08:40:24PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 05, 2001 at 08:34:30PM -0700, Ian Holsman wrote:
> > 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.
> 
> Aaron and I went back and forth on this.  He was of the mind that
> the user scheduler should figure it out after a period of time
> (and that we shouldn't muck with it).

Actually, I seem to recall suggesting that we add something like
apr_thread_setconcurrency() that attempts to do the right thing if the
platform supports it (and if it doesn't, it's probably no big deal),
and is otherwise just a noop. This may help solaris adapt quicker to a
fast ramp-up of userspace-to-LWP thread mapping, especially when there
are many compute-bound threads that are initially unwilling to yield. I
have a feeling this may be more important on SMP boxes, where threads
should be migrated to become bound threads as soon as possible.


> The badness happens in testthread.c - Solaris executes that code
> in serial since the user scheduler never has a chance to 
> interrupt and balance the threads.  But, in the "real" code, 
> Solaris balances it since we hit syscalls and mutexes quite often.
> 
> An equivalent to calling pthread_setconcurrency is to use
> /usr/lib/lwp/libthread.so instead of /usr/lib/libthread.so.

ISTR that this will cause every thread to become a bound thread, effectively
eliminating the [theoretical] benefits of a partial userspace thread impl.

-aaron

Mime
View raw message