2.0.x SMP performances compared to 2.1.x

Claude Gamache (cgamache@cae.ca)
27 Aug 1998 17:42:26 -0400


(this message was posted to kernel-smp, but we forgot to copy
it to linux-kernel)

Hi,

Our question is about performance of kernels 2.0.x compared to 2.1.x
kernels.

Our application is built with egcs 1.0.3 and is made up of 10
processes sharing information through shared memories (up to 10
maximum). In order to avoid racing situations among the processes we
use sigaction() and setitimer() to schedule each process execution,
and some of the processes have a priority of +19. So when a process
has finished its computation it gently waits in the pause() function,
requiring almost no CPU time at all. The computations are arranged in
a pipeline going from one process to the next. When one process does
not have any new data, it simply goes directly to the pause() function
in order to be nice to the other processes.

The result of the computations is a picture continuously updated on
the screen. To display the picture we mainly use XDrawPoints() in 8
bpp (XFree86 3.3.2 and AGP Matrox Millenium II with 8 Mb RAM).

The tested computer is an IBM Intellistation M Pro with two Pentium II
400 MHz with 512 kb cache. The system has 256 Mb RAM (100 MHz RAM) and
is equipped with a 9 Gb IBM SCSI disk connected to an AIC-7895
(Adaptec 2940) scsi adapter. When the program runs, the kernel does
not need to swap, since there is enough RAM available. The GNU/Linux
distribution is Red Hat 5.1 with upgrades applied and glibc version is
2.0.7.

With kernel 2.1.117 SMP, the overall performances degrade by
approximatively 20% compared with kernel 2.0.35 SMP. That is, with
kernel 2.1.117 it takes 1.2 times longer to carry the same amount of
computations on a 2.0.35 kernel.

We also tried nbench 2.1 with 2.0.35 and 2.1.117 kernels. Although,
this time we did not see any performance degradation, results were
identical with 2.0.35 and 2.1.117. The nbench benchmark does not use
any IPC or socket, so perhaps something fundamental has changed in the
IPC/socket handling by the kernel ?

Is the 2.1.x kernel running some profiling code even when we don't
select the kernel hacking option in "menu xconfig" ?

What are your personal results ? Does anybody have noticed a
performance degradation or are we doing something wrong ?
Are there things we should avoid doing in 2.1.x kernels ?

In the 2.1.117 kernel, we have the mtrr (memory type range register)
support. When we activated the mtrr for the video card at the prompt
(by following the instructions of the mtrr documentation), things got
even worse, performances dropped by about 50% ! According to the mtrr
documentation we should have seen improvements. We also tried mtrr
with a dual IBM Intellistation Z Pro equipped with 2 Pentium Pro 200
MHz 512 kb cache running kernel 2.1.115 and, again, we got a
performance degradation when we enabled mtrr.

Basically, we want to improve (or at least get same performance) the
execution performance of our application. With 2.0.x kernels, we have
seen a lot of improvement each time we optimized our code (C language
only) and now when we run the same code with a 2.1.x kernel on the
same computer, we experience performance degradation :-(

The optimisations done in the code improved overall performances in
2.1.117 too, but kernel 2.1.117 is still slower than 2.0.35

We also ran a profiler test as suggested by Andi Kleen <ak@muc.de>
(thanks Andi), we posted the results in kernel-smp, we can repost it
here if you want. We don't really understand the result of the
profiling test ;-)

Comments and/or advices are warmly welcomed.

Thanks in advance for your help

Regards,

Claude Lefrancois and Claude Gamache

-- 
  Claude Gamache, CAE Electronique Ltee, 8585 Cote-de-Liesse  
  Saint-Laurent,  Quebec, Canada H4T 1G6                        
  Email: cgamache@cae.ca  Tel.: (514) 341-2000 x3194

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html