Re: Performance counters and profiling on MIPS

[Ralf Baechle <ralf@linux-mips.org>]

On Wed, Jun 07, 2006 at 10:22:52AM -0700, Jonathan Day wrote:

> Two quick and semi-related questions for the Gurus of
> the MIPS. First off, it would appear that profiling on
> any of the Broadcom MIPS processors is broken. I get
> the following warnings when compiling the
> platform-specific irq.c file:

This is ZBus-based profiling which also isn't supported by the standard
profiling tool oprofile.  Oprofile is using the performance counters of
the processor itself.

> My second question is with regards to accessing the
> performance counters and timestamp counters from
> userspace. On some architectures, this is as simple as
> using a single macro.
> 
> In the case of the ix86 architecture (yuk!), the
> timestamp counters can be read with nothing more than
> an rdtsc() call, as follows:
> 
> asm volatile ("rdtsc" : "=a"(*(elg_ui4
> *)&clock_value),
>                 "=d"(*(((elg_ui4 *)&clock_value)+1)));
> 
> What is the closest equiv. for the MIPS processors?

On most R4000-style processors (that includes the SB1 core of the Sibyte
chips) applications can access the cycle counter through an
mfc0 $reg, $c0_count instruction.  However mfc0 is a priviledged
instruction, so that doesn't work for code that doesn't have kernel
priviledges.

For release 2 of the MISP32 / MIPS64 architecture there is a new
instruction, rdhwr which an application - so the OS permits it - can
use to read c0_count.

Now there are two problems with that approach in your case:

 o SB1 implements release 0.95 of the MIPS64 architecture, SB1A release 1.
   Iow these cores don't have rdhwr.
 o In general on a multiprocessor system you don't have a guarantee that
   the count registers of all processors are running at the same speed or
   were set to the same value at any time.
      This is more of a general problem; in case of the BCM1250 the cores
   are actually running at the same speed and afair are synchronized by
   the reset.

  Ralf