[Bug runtime/20961] New: ppc64 time initialization

["dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20961

            Bug ID: 20961
           Summary: ppc64 time initialization
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

As a part of investigating bug #20600, I looked at __stp_get_freq() (in
runtime/time.c). That function tries to return the cpu's frequency (in kHz). It
has several arch-specific sections of code, then tries a generic default
estimate.

There was no arch-specific section for ppc64, so I added one, based on the code
the kernel runs when /proc/cpuinfo is displayed. Later I found a more generic,
arch-independent method, calling cpufreq_quick_get() on kernels with
CONFIG_CPU_FREQ.

This new code seems to work well, except on ppc64. To illustrate this, I've
written a script that uses embedded code to try the arch-independent method,
the arch-specific method, and the generic estimate.

On x86_64 (3.10.0-514.el7.x86_64):

# grep Hz /proc/cpuinfo | head -n 1
cpu MHz         : 4000.000

# stap -g get_freq.stp
generic freq:  4000000
arch freq:     3991335
estimate freq: 3990586

So in the above output, the /proc/cpuinfo clock rate and the generic frequency
match (once you convert the MHz to kHz). The arch-specific frequency and
estimates are quite close.

On ppc64 (3.10.0-514.el7.ppc64.debug) I see the following:

# fgrep clock /proc/cpuinfo | head -n 1
clock           : 3425.000000MHz

# stap -g get_freq.stp
generic freq:  0
arch freq:     3425000
estimate freq: 511923

So, here, the generic method fails (it is documented that it can fail), and the
new code's arch-specific method matches what /proc/cpuinfo shows (once you
convert MHz to kHz). However, the estimated frequency doesn't match at all with
the arch-specific frequency.

When I do a testsuite run with the new much higher frequency, gtod.exp (and
others) fail.

More investigation is needed here.

-- 
You are receiving this mail because:
You are the assignee for the bug.