Re: gprof & Linux interaction oddity

[Ian Lance Taylor <ian at airs dot com>]

Tres Melton <tres@mindspring.com> writes:

> 	There is an issue with gprof and getting the current OS' Hz from the
> elf header in Linux via sysconf().  That value is always set to 100 Hz
> and it is playing games with profiling code. I have been in contact with
> a number of the kernel developers and we are preparing to take this
> issue to the LKML.  There is a bug on RedHat's bugzilla regarding this
> issue and a more detailed report in Gentoo's bugzilla:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=90090
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151763
> 
> 	Most of the developers that I have spoken with, including Andrew Morton
> and John Mylchreest, are in favor of correcting this issue but Linus has
> previously ruled against it.  We are hoping that he will reconsider
> since the merging of the configurable user hz patch in 2.6.13-rc3.
> 
> 	One of the developers, Robert Love, has responded:  "Explain why gprof
> needs to know the _actual_ timing tick."  I was hoping that you could
> help me with that.

gprof as such doesn't need to know the timing tick.  The profiling
rate is read out of the gmon.out file written by glibc.  glibc appears
to compute the rate like this (sysdeps/unix/sysv/linux/prof-freq.c):

  tim.it_interval.tv_sec = 0;
  tim.it_interval.tv_usec = 1;
  tim.it_value.tv_sec = 0;
  tim.it_value.tv_usec = 0;

  __setitimer (ITIMER_REAL, &tim, 0);
  __setitimer (ITIMER_REAL, 0, &tim);

  if (tim.it_interval.tv_usec < 2)
    return 0;

  return 1000000 / tim.it_interval.tv_usec;

So if you are using glibc, I would not expect gprof to make the
sysconf call at all.

gprof only uses the timing tick to report times correctly.  If the
timing tick is incorrect in the gmon.out file, gprof will report the
wrong numbers for how long it takes to execute a function.  The
percentages should still be correct, though.

Ian