0

I am using oprofile to tune the performance of my application. Below is how I collected the profiling data:

platform info: virtual machine (KVM-based), linux kernel 2.6.21, x86 64bit, 

1. opcontrol --init
2. opcontrol --no-vmlinux -p library -c 100
3. opcontrol --status

Separate options: library
vmlinux file: none
Image filter: none
Call-graph depth: 100

4. opcontrol -s
5. /*running my application*/
6. opcontrol -h
7. opreport -l my_application

20136     0.0000  no-vmlinux               no-vmlinux               /no-vmlinux
1311      0.0000  libcrypto.so.0.9.8       lighttpd                 /opt/ccnsr/lib64/libcrypto.so.0.9.8
455       0.0000  libxml2.so.2.6.26        my_application                     /opt/ccnsr/lib64/libxml2.so.2.6.26
350       0.0000  libc-2.5.90.so           my_application           _int_malloc
195       0.0000  libpython2.4.so.1.0      python                   PyEval_EvalFrame
142       0.0000  libc-2.5.90.so           my_application           vfprintf
79        0.0000  libc-2.5.90.so           my_application           _IO_default_xsputn

The "%" column of opreport always showed 0.0000!

CharlesB
  • 86,532
  • 28
  • 194
  • 218
lws
  • 21
  • 3

1 Answers1

0

If you write a little app that mainly does I/O, and sample on wall-clock (not CPU) time, and display exclusive percent, you will see every percent is very near zero.

The reason is that the program spends nearly all of its time waiting for the previously initiated IO to complete. So the fraction of time it spends in any routine is almost nothing, compared to the fraction of time it spends waiting.

Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • The root cause seems the mismatch between customized glibc and gcc, which cause floating calculation fail. Thanks for your response. – lws Apr 18 '12 at 06:59