Philip,
So far the build without the --disable-nonportable-atomics flag seems to
working much better with httpd 2.2.29, svn 1.8.13, and apr 1.5.1. I'm no
longer seeing the assert when using the worker mpm on a heavily loaded
multi-core system.
Thanks!
Kevin R.
On Wed, Apr 15, 2015 at 11:26 AM, Kevin Radke <kmradke_at_gmail.com> wrote:
> Philip,
>
> I believe the non-portable-atomics flag is left over from getting 1.7
> working due to the original APR bug. Since the bug is fixed, I'll try
> without the flag and see what happens.
>
> A make check for this apr also succeeds without any issues.
>
> APR Lock Performance Test
> ==============
>
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 1 threads OK
> microseconds: 24476 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 1 threads OK
> microseconds: 30257 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 1 threads OK
> microseconds: 42559 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 2 threads OK
> microseconds: 48643 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 2 threads OK
> microseconds: 49841 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 2 threads OK
> microseconds: 88017 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 3 threads OK
> microseconds: 71369 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 3 threads OK
> microseconds: 74264 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 3 threads OK
> microseconds: 156797 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 4 threads OK
> microseconds: 98064 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 4 threads OK
> microseconds: 99977 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 4 threads OK
> microseconds: 258812 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 5 threads OK
> microseconds: 122259 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 5 threads OK
> microseconds: 125806 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 5 threads OK
> microseconds: 344890 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (UNNESTED) OK
> Starting 6 threads OK
> microseconds: 146183 usec
> apr_thread_mutex_t Tests
> Initializing the apr_thread_mutex_t (NESTED) OK
> Starting 6 threads OK
> microseconds: 149457 usec
> apr_thread_rwlock_t Tests
> Initializing the apr_thread_rwlock_t OK
> Starting 6 threads OK
> microseconds: 490974 usec
> Trying proc mutexes with mechanism `default'...
> Mutex mechanism `default' is global in scope on this platform.
> Trying global mutexes with mechanism `default'...
> no problems encountered...
> Trying proc mutexes with mechanism `flock'...
> Mutex mechanism `flock' is not global in scope on this platform.
> Trying global mutexes with mechanism `flock'...
> no problems encountered...
> Trying proc mutexes with mechanism `sysvsem'...
> Mutex mechanism `sysvsem' is global in scope on this platform.
> Trying global mutexes with mechanism `sysvsem'...
> no problems encountered...
> Trying proc mutexes with mechanism `posix'...
> Mutex mechanism `posix' is global in scope on this platform.
> Trying global mutexes with mechanism `posix'...
> no problems encountered...
> Trying proc mutexes with mechanism `fcntl'...
> Mutex mechanism `fcntl' is not global in scope on this platform.
> Trying global mutexes with mechanism `fcntl'...
> no problems encountered...
> Trying proc mutexes with mechanism `proc_pthread'...
> Mutex mechanism `proc_pthread' is global in scope on this platform.
> Trying global mutexes with mechanism `proc_pthread'...
> no problems encountered...
> testatomic : SUCCESS
>
> Kevin R.
>
> On Wed, Apr 15, 2015 at 10:30 AM, Philip Martin <
> philip.martin_at_wandisco.com> wrote:
>
>> Kevin Radke <kmradke_at_gmail.com> writes:
>>
>> > I'm using --disable-nonportable-atomics and apr 1.5.1 compiled with gcc
>> > 4.4.7.
>> > httpd 2.2.29 is built with mpm=worker.
>>
>> Do you have a particular reason for using --disable-nonportable-atomics?
>> I suspect it leads to code that is not used as often and thus less well
>> tested. Perhaps try building apr without that setting.
>>
>> > make check in svn gives:
>> > Summary of test results:
>> > 1948 tests PASSED
>> > 58 tests SKIPPED
>> > 31 tests XFAILED (1 WORK-IN-PROGRESS)
>> > SUMMARY: All tests successful.
>>
>> The APR regression tests probably exercise the atomic code more than the
>> Subversion regression tests.
>>
>> --
>> Philip Martin | Subversion Committer
>> WANdisco // *Non-Stop Data*
>>
>
>
Received on 2015-04-16 15:55:31 CEST