Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 24 Jul 2001 12:14:00 -0700
From: Aaron Bannert <aaron@ebuilt.com>
To: new-httpd@apache.org
Subject: Re: OSDLab projectL Accept() locking on large (6+ CPU) boxes
Message-ID: <20010724121400.O28176@ebuilt.com>
References: 
 <Pine.OSX.4.33.0107241039310.3569-100000@titatovenaar.sfo.covalent.net>
 <20010724110730.L28176@ebuilt.com> <3B5DBF39.2000609@pacbell.net>
 <20010724115437.M26972@ebuilt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010724115437.M26972@ebuilt.com>;
 from jerenkrantz@ebuilt.com on Tue, Jul 24, 2001 at 11:54:37AM -0700

On Tue, Jul 24, 2001 at 11:54:37AM -0700, Justin Erenkrantz wrote:
> On Tue, Jul 24, 2001 at 11:32:25AM -0700, Brian Pane wrote:
> > Are you able to observe this effect experimentally too?  E.g., if
> > you run the threaded MPM on Solaris, does it use just one LWP per
> > process?
> 
> Not with threaded MPM because it uses blocking system calls which allow
> Solaris's scheduler to jump in and rebalance.  Initially, it'll be
> one LWP, but after some load hits, it should spawn multiple LWPs and
> rebalance the threads accordingly.
> 
> However, try testthread on Solaris (with an MP box) and it'll execute 
> all of the threads in serial rather than parallel.  This is what drove
> me crazy last night - forcing me to comb through the manpages until I
> hit upon the pthread_setconcurrency call. 
> 
> By leveraging the pthread_setconcurrency call, the threads are balanced
> across LWPs immediately rather than waiting for each thread to hit a
> blocking system call or yield.  -- justin

That's not necessarily true. According to the man page (on solaris),
by default the OS will only ensure that a sufficient number of threads
(aka LWPs) are active to ensure that the process can continue to make
progress. Who knows what they mean by "can continue to make progress",
but to me this means the most conservative case -- basicly act like a purely
userspace implementation and just multiplex the one main thread.

Anyway, pthread_setconcurrency() is just a hint to the OS as to the level
of concurrency you wish to have, it's no guarantee that it will actually
assign that many active threads (LWPs) to your userspace threads.

Does anyone know of a good place to read about the dirty details of
solaris M-to-N (aka two-level) thread implementation?

-aaron