On Sun, Sep 16, 2001 at 03:29:37PM -0700, Aaron Bannert wrote:
(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
On Sun, Sep 16, 2001 at 04:12:58PM -0700, Justin Erenkrantz wrote:
Yup. More precisely /usr/lib/lwp/libthread.so is the alternate
version and /usr/lib/libthread.so is the default version. They
are binary compatible (as far as we care) - therefore the
LD_LIBRARY_PATH trick works. With
Justin Erenkrantz wrote:
On Sun, Sep 16, 2001 at 04:12:58PM -0700, Justin Erenkrantz wrote:
Yup. More precisely /usr/lib/lwp/libthread.so is the alternate
version and /usr/lib/libthread.so is the default version. They
are binary compatible (as far as we care) - therefore the
LD_LIBRARY_PATH
On Sun, Sep 16, 2001 at 04:12:58PM -0700, Justin Erenkrantz wrote:
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
On Sun, Sep 16, 2001 at 07:11:41PM -0700, Aaron Bannert wrote:
The only platforms that I know about that have a two-level thread model
are AIX and Solaris. The single-level thread libs ignore setconcurrency
because every thread is what solaris calls a bound thread, or a kernel
scheduled entity
On Sun, Sep 16, 2001 at 12:55:10AM -0700, Justin Erenkrantz wrote:
I'm saying that it should never be used. Simple. You can't use
that call properly in any real-world case - just like I don't think
you should call sched_yield ever. You are attempting to solve a
problem that is best solved
On Sun, Sep 16, 2001 at 07:44:58PM -0700, Justin Erenkrantz wrote:
On Sun, Sep 16, 2001 at 07:11:41PM -0700, Aaron Bannert wrote:
The only platforms that I know about that have a two-level thread model
are AIX and Solaris. The single-level thread libs ignore setconcurrency
because every
On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
I don't think it's a quirk of the thread library, I think it's
fully expected. For the sake of others, here's an excerpt from the
Solaris 8 pthread_setconcurrency(3THR) man page:
In testlockperf, you are assuming that all of the
On Sun, Sep 16, 2001 at 08:13:25PM -0700, Justin Erenkrantz wrote:
On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
I don't think it's a quirk of the thread library, I think it's
fully expected. For the sake of others, here's an excerpt from the
Solaris 8
On Sun, Sep 16, 2001 at 08:30:15PM -0700, Aaron Bannert wrote:
Agreed, but instead of adding sleep we should:
a) call pthread_setconcurrency()
b) devise a more life-like test
c) not do anything cause it's working fine
testlockperf is really just trying to gauge the overhead from the
mutex
On Sunday, 16 Sep 2001, at 20:05:00,
Aaron Bannert wrote:
I wouldn't be surprised if it did the same thing as Solaris on
testlockperf. It remains to be seen, however, how the libs perform
on Solaris/AIX under real-world scenarios (worker MPM) w/ and w/o
setconcurrency, and on Uni and
On Sun, 2001-09-16 at 20:13, Justin Erenkrantz wrote:
On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
I don't think it's a quirk of the thread library, I think it's
fully expected. For the sake of others, here's an excerpt from the
Solaris 8 pthread_setconcurrency(3THR) man
On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
On Sun, Sep 16, 2001 at 12:55:10AM -0700, Justin Erenkrantz wrote:
You also haven't mentioned how many LWPs it stabilized at after
10 seconds? Did Solaris choose to add a LWP for each user thread?
I have a feeling it
Aaron Bannert wrote:
On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
On Sun, Sep 16, 2001 at 12:55:10AM -0700, Justin Erenkrantz wrote:
You also haven't mentioned how many LWPs it stabilized at after
10 seconds? Did Solaris choose to add a LWP for each user thread?
I have a
On Mon, Sep 17, 2001 at 10:17:16AM -0700, Brian Pane wrote:
So that's 25 ThreadsPerChild + 3 builtin threads (door server, door
client, reaper) = 28, so yeah, it stabalized to the number of simultaneous
requests I expect to handle (aka the number of worker threads).
How were you handling 25
If you create too many LWPs, you will lose a lot of optimizations
that are present in Solaris (i.e. handover of a mutex to another
thread in the same LWP - as discussed with bpane on [EMAIL PROTECTED]
recently). If you don't create enough LWPs, you may enter a
condition where the scheduler
Aaron Bannert wrote:
On Mon, Sep 17, 2001 at 10:17:16AM -0700, Brian Pane wrote:
So that's 25 ThreadsPerChild + 3 builtin threads (door server, door
client, reaper) = 28, so yeah, it stabalized to the number of simultaneous
requests I expect to handle (aka the number of worker threads).
How were
On Fri, Sep 14, 2001 at 06:33:47PM -0700, Justin Erenkrantz wrote:
On Fri, Sep 14, 2001 at 04:21:51PM -0700, Aaron Bannert wrote:
Why would this circumvent the OS scheduler at all? In all cases it
is a *hint*. Please be more precise.
I think I showed you an example awhile ago where
On Fri, Sep 14, 2001 at 08:16:03PM -0700, Ian Holsman wrote:
+1 IF the number you set it to is a hint, and solaris can changes the
concurrency afterwards according to the load on the system/internal
guidelines.
This is how it appears to work according to the source. I'll try fooling
with
On Sat, Sep 15, 2001 at 04:43:39PM -0700, Aaron Bannert wrote:
If you create too many LWPs, you will lose a lot of optimizations
that are present in Solaris (i.e. handover of a mutex to another
thread in the same LWP - as discussed with bpane on [EMAIL PROTECTED]
recently).
Of
On Sun, Sep 16, 2001 at 12:55:10AM -0700, Justin Erenkrantz wrote:
The testlock case doesn't matter because it never hits any of the
Solaris-defined entry points. This is a quirk in the OS and I see
no reason to work around it. If you want to make testlock do the
right thing with the
On Fri, Sep 14, 2001 at 08:16:03PM -0700, Ian Holsman wrote:
Oh...
I ran the the testlockperf code on the 8-way box, with
the pthread_setconcurrency calls commented out, and with
the concurrency calls put in (setting them to 8).
results are as follows
Could you rerun this test with
On Sun, 2001-09-16 at 11:21, Justin Erenkrantz wrote:
On Fri, Sep 14, 2001 at 08:16:03PM -0700, Ian Holsman wrote:
Oh...
I ran the the testlockperf code on the 8-way box, with
the pthread_setconcurrency calls commented out, and with
the concurrency calls put in (setting them to 8).
On Sun, Sep 16, 2001 at 01:53:42PM -0700, Ian Holsman wrote:
$ ./testlockperf
APR Lock Performance Test
==
apr_lock(INTRAPROCESS, MUTEX) Lock Tests
Initializing the apr_lock_t OK
Starting all the threadsOK
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
On Fri, Sep 14, 2001 at 03:49:59PM -0700, Justin Erenkrantz wrote:
On Fri, Sep 14, 2001 at 03:44:48PM -0700, Aaron Bannert wrote:
I'd like to propose we add a call that gives a hint to the OS as to
the level of concurrency we wish to have. This would mirror
pthread_setconcurrency(), and
On Friday 14 September 2001 03:44 pm, Aaron Bannert wrote:
+1
Ryan
I'd like to propose we add a call that gives a hint to the OS as to
the level of concurrency we wish to have. This would mirror
pthread_setconcurrency(), and would be a simple call to that on
operating systems that have it
On Fri, Sep 14, 2001 at 04:21:51PM -0700, Aaron Bannert wrote:
Why would this circumvent the OS scheduler at all? In all cases it
is a *hint*. Please be more precise.
I think I showed you an example awhile ago where compute-bound threads
behave drastically different depending on the
Aaron Bannert wrote:
I'd like to propose we add a call that gives a hint to the OS as to
the level of concurrency we wish to have. This would mirror
pthread_setconcurrency(), and would be a simple call to that on
operating systems that have it available. On other platforms it
would be simple noop.
I'd like to propose we add a call that gives a hint to the OS as to
the level of concurrency we wish to have. This would mirror
pthread_setconcurrency(), and would be a simple call to that on
operating systems that have it available. On other platforms it
would be simple noop.
Give me some +1s
On Fri, Sep 14, 2001 at 03:44:48PM -0700, Aaron Bannert wrote:
I'd like to propose we add a call that gives a hint to the OS as to
the level of concurrency we wish to have. This would mirror
pthread_setconcurrency(), and would be a simple call to that on
operating systems that have it
31 matches
Mail list logo
