runtime: implement cputicks using MRC(PMCCNTR) on arm

[dvyukov]

Current implementation of cputicks on ARM is very low precision which hurts block profile and tracer.

http://gperftools.googlecode.com/svn/trunk/src/base/cycleclock.h
contains lots of goodness, and in particular cputicks implementation for arm:

#elif defined(ARMV3)
#if defined(ARMV6)  // V6 is the earliest arch that has a standard cyclecount
    uint32 pmccntr;
    uint32 pmuseren;
    uint32 pmcntenset;
    // Read the user mode perf monitor counter access permissions.
    asm volatile ("mrc p15, 0, %0, c9, c14, 0" : "=r" (pmuseren));
    if (pmuseren & 1) {  // Allows reading perfmon counters for user mode code.
      asm volatile ("mrc p15, 0, %0, c9, c12, 1" : "=r" (pmcntenset));
      if (pmcntenset & 0x80000000ul) {  // Is it counting?
        asm volatile ("mrc p15, 0, %0, c9, c13, 0" : "=r" (pmccntr));
        // The counter is set up to count every 64th cycle
        return static_cast<int64>(pmccntr) * 64;  // Should optimize to << 6
      }
    }
#endif

Should consider switching to it.

There is also an impl for power processors.

[dvyukov]

@minux @davecheney

[minux]

The problem is that not all kernel allow user access to performance counters. I tried to read pmuseren, but the result is 0 with an old 3.0 kernel.

[davecheney]

That was my suspicion as well, I don't see how the kernel could multiplex these singleton resources across anyone who could whip up an MRC instruction.

On 16 Feb 2015, at 19:40, Minux Ma notifications@github.com wrote:

The problem is that not all kernel allow user access to performance
counters.

I tried to read pmuseren, but the result is 0 with an old 3.0 kernel.
—
Reply to this email directly or view it on GitHub.

[crawshaw]

We discussed this recently on #9725 (in fact this may be a duplicate). The best I could find was perf_event_open, which still requires a read syscall.

[bradfitz]

Time to punt this to Go 1.6?

[rsc]

Dup of #9725