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 Fri, 14 Sep 2001 23:21:51 GMT
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 would be a simple call to that on
> > operating systems that have it available. On other platforms it
> > would be simple noop.
> 
> The problem with this is that we are going to circumvent the OS
> scheduler which I think is a bad idea - unless we can show where the 
> OS falls down on the job (except in the pedantic case of testthread).
> -- justin

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 operating system. In
the case of solaris, a computationally intensive thread that makes no
system calls* will not automatically yield a mutex when entering/exiting
a critical section, unless pthread_setconcurrency() is called.

In a practical sense, when I was playing with the worker MPM I noticed
that under high load (maxing out the CPU) it took on the order of 10
seconds** for the number of LWPs to stablize.

*Really, these are calls that check the userspace run-queue.

**A number I pulled out of my arse...it took awhile at least. Once it
stabalized, the system could handle the load with a few extra cycles to spare.
I'm not sure if it's significant for the worker MPM, but I can show cases
where it is significant.

-aaron

Mime
View raw message