By the way, it would be interesting to see what results other people are
getting on Linux 2.4 and 2.6 in single and multiple processor
configurations. My CPU burner is just:
main() { for(;;); }
compiled with gcc -O4.
Edit include/portable.h and undef REPLACE_BROKEN_YIELD and
HAVE_NANOSLEEP to get a baseline build. To save time getting the other
numbers, just recompile libldap_r/thr_posix.c for the subsequent tests:
rm libldap_r/thr_posix.*o
make DEFINES=-DREPLACE_BROKEN_YIELD
... test ...
rm libldap_r/thr_posix.*o
make DEFINES="-DREPLACE_BROKEN_YIELD -DHAVE_NANOSLEEP"
... test ...
Howard Chu wrote:
I did some more timing of test008 with and without a background CPU
burning job. (just a for loop, so it had minimal impact on CPU cache.)
On a 2GHz Pentium-M laptop with Linux 2.6.5:
test008 test008+CPU job
original 0:27 1:10
BROKEN/select 0:24 0:24
BROKEN/nano 0:33 0:33
On 2GHz AMD64 X2 with Linux 2.6.14 (SMP):
original 0:31 0:43
BROKEN/select 17:09 17:47
BROKEN/nano 1:28 1:29
I have a feeling we're going to be seeing pretty varied results across
a range of configurations. My feeling is we're best off using
sched_yield(), and possibly using the SCHED_FIFO scheduler to get
deterministic performance on 2.6 kernels. I'm also inclined to just
back out all of this stuff and completely ignore the issue, as I did
before. There's no good reason to have other jobs soaking up the CPU
on the same machine as your infrastructure services.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
