apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: [proposal] apr_thread_setconcurrency()
Date Sun, 16 Sep 2001 22:29:37 GMT
On Sun, Sep 16, 2001 at 02:02:39PM -0700, Justin Erenkrantz wrote:
> This is on a 8-way box, right?  Those numbers look about right
> for the bound thread implementation.  However, the LWP version
> still looks like it isn't doing the right thing.

(just a question, when you say "bound thread impl" you mean
/usr/lib/lwp/libpthread, right? and the "LWP version" is the default
/usr/lib/libpthread. Let me know if I have this backward. Maybe
"LWP version" isn't the best name for the two libs, since they both
do LWPs.)

> I think you probably need this patch for the LWP version. 
> I'm not sure whether setconcurrency will produce the same 
> effect - it might.
> I'm not going to commit this because I know it's the wrong thing 
> (should be condition vars I think), but it solves the scheduling 
> quirk on Solaris for now.  -- justin

I don't really see this as a scheduling quirk on Solaris. I think we
would all agree that the same "work" is performed in each of the 4 tests,
with or without sleeps, and with or without setconcurrency.  It is also
obvious that since the same "work" is performed in each case, that the
obvious winner for this made-up performance test is the one that does
the work the fastest; which happens to be the one that creates no new
LWPs and therefore minimizes the number of kernel context switches.

But of course that case is not terribly relevant for something like
httpd-2.0 on a big SMP box, where the optimal case (of which there are
many dimentions) can not be known to the underlying thread/LWP creation
agent. That is the key issue at hand here. We, as _users_ of this API
would like to maximize each of {requests/second, time/request, number of
simultaneous connections} where the LWP creation agent is just trying to
get the work done with the least amount of context switching. The dials it
has to play with are numerous, and so it must perform a delicate linear
programming task in an attempt to meet the same goals as the application
programmer. I don't claim that setconcurrency is the way to reduce the
number of variables in this equation, but I do suggest we may want to
take this into consideration when trying to make our threaded algorithms
work the way we expect them to.


View raw message