Re: ITS#3950

[Howard Chu <hyc@symas.com>]

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/