Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
User updated by: stefan at whocares dot de
Reported by: stefan at whocares dot de
Summary: fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package: FPM related
Operating System: Linux (Debian for Sparc)
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
Thanks for your input, greatly appreciated.
It'd be nice if you could help me out a bit more. I grepped through the
whole
source and the only use of 'atomic_cmp_set' I could find was within
fpm_atomic.h
itself:
(333)sparky:~/devel/build/php5-5.3.3# grep -R 'atomic_cmp_set' *
sapi/fpm/fpm/fpm_atomic.h:static inline atomic_uint_t
atomic_cmp_set(atomic_t
*lock, atomic_uint_t old, atomic_uint_t set) /* {{{ */
sapi/fpm/fpm/fpm_atomic.h:static inline atomic_uint_t
atomic_cmp_set(atomic_t
*lock, atomic_uint_t old, atomic_uint_t set) /* {{{ */
sapi/fpm/fpm/fpm_atomic.h:static inline atomic_uint_t
atomic_cmp_set(atomic_t
*lock, atomic_uint_t old, atomic_uint_t set) /* {{{ */
sapi/fpm/fpm/fpm_atomic.h:static inline atomic_uint_t
atomic_cmp_set(atomic_t
*lock, atomic_uint_t old, atomic_uint_t set) /* {{{ */
sapi/fpm/fpm/fpm_atomic.h:static inline atomic_uint_t
atomic_cmp_set(atomic_t
*lock, atomic_uint_t old, atomic_uint_t set) /* {{{ */
sapi/fpm/fpm/fpm_atomic.h: return atomic_cmp_set(lock, 0, 1) ? 0 :
-1;
sapi/fpm/fpm/fpm_atomic.h: if (atomic_cmp_set(lock, 0, 1)) {
(333)sparky:~/devel/build/php5-5.3.3#
Since you're saying it's a general purpose function I'm obviously
missing
something here and because I'm an enquiring mind I'd like to know what
it is I'm
missing.
I agree that using C code would improve portability. But since the
machine I'm
building for is slow enough already, I'd prefer to stick with assembler
if
possible,
Previous Comments:
------------------------------------------------------------------------
[2010-11-24 01:44:04] [email protected]
well, what i meant by 'in this context' is -> the compare and set is a
general
purpose function within fpm and is not intended to simply test&swap a
single
byte . hence, it won't be appropriate to replace cas with ldstub
instruction.
also, what i meant by not using the atomic option is - fpm currently
implements
varieties of common api's by using assembly instructions. It is possible
to do
the same by using mutex lock and regular c code. this alternate way
allows some
one to run in varieties of architecture. though, this might run slightly
slower.
doing this way would be a better option for your case.
------------------------------------------------------------------------
[2010-11-18 12:30:43] stefan at whocares dot de
As per request here the results when running 'ab' against a patched
version of
PHP 5.3.3 running on the ReadyNAS.
Environment:
============
Web Server: Nginx 0.8.53
PHP-FPM : Running with dynamic processes, 2 min, 2 minspare, 3
maxspare
Please keep in mind that the CPU of the ReadyNAS is running at whooping
186 MHz,
so the results obviously won't be lightning fast:
Results:
========
desktop:~$ ab -c 100 -n 10000 http://develnas:8880/test.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking develnas (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx/0.8.53
Server Hostname: develnas
Server Port: 8880
Document Path: /test.php
Document Length: 16 bytes
Concurrency Level: 100
Time taken for tests: 110.629 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1700000 bytes
HTML transferred: 160000 bytes
Requests per second: 90.39 [#/sec] (mean)
Time per request: 1106.289 [ms] (mean)
Time per request: 11.063 [ms] (mean, across all concurrent
requests)
Transfer rate: 15.01 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.6 0 10
Processing: 105 1101 212.8 1122 2348
Waiting: 105 1100 212.8 1121 2348
Total: 107 1101 212.7 1122 2349
Percentage of the requests served within a certain time (ms)
50% 1122
66% 1129
75% 1139
80% 1145
90% 1547
95% 1552
98% 1564
99% 1571
100% 2349 (longest request)
desktop:~$
------------------------------------------------------------------------
[2010-11-18 02:11:10] stefan at whocares dot de
Thank you for your input. Just so I understand better:
You said "in this context is not what we want". Could you clarify that a
bit? As
far as I understand the code (and I don't claim to fully understand it)
it just
checks whether if a specific memory region contains a value of "0" and
if so, it
tries to set it to "1". At least I couldn't find any calls to the atomic
"add"
functions although they are provided for some architectures.
Also you said: "not using 'atomic' operation will be the better approach
for
your scenario". Would you have an example / explanation on how to do
that? I'd
really be interested in that so I could eventually come up with a good
and
working solution.
------------------------------------------------------------------------
[2010-11-18 01:53:37] sriram dot natarajan at gmail dot com
there is difference between these 2 instructions:
ldstub -> operates on a 8 byte value
casa -> operates on a 32-bit word
now, if some one wanted to use these instructions to implement a atomic
mutex
lock, then one could argue that both instruction set are
interchangeable. in
this case, that is not the case. hence, i would argue that there is a
valid case
for using this specific 'compare and swap' instruction set.
using 'ldstub instruction set' in this context is not what we want.
few curl or http get requests cannot display the potential race
conditions.
not using 'atomic' operation will be the better approach for your
scenario.
------------------------------------------------------------------------
[2010-11-17 08:27:31] [email protected]
one simple test is to make php core the less as possible. You can create
a file
test.php wich does nothing but an "echo".
Then you stress this page with FPM with ab (ab -c 100 -n 10000
http://ip:port/test.php
While the test is running you check the status page and see how it's
goin' on.
it should be a good primary test.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
