[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#3950

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
... test ...
rm libldap_r/thr_posix.*o
... 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/