5

I have noticed there are some profiling source code under arch/arm/kernel:

perf_event.c 
perf_event_cpu.c 
perf_event_v6.c 
perf_event_v7.c 
perf_event_xscale.c

I can't understand the hierarchy of those files and how can I use them? can I assume they are always exists and use them in a kernel module? my kernel module runs on Cortex-A7 or Cortex-A15 cores.

There seems to be a lot of very useful things under /arch/arm/kernel/ directory but no documentation about the capabilities ? how comes ?

0x90
  • 39,472
  • 36
  • 165
  • 245
  • Can you instead use the `perf` userspace tool which is popular on x86-style targets? Or do you actually need access to perfcounters from the kernel? – Brian Cain Sep 06 '13 at 17:16
  • I need both, I have one user space application on Android platform and a kernel module I write which I can't use perf with it. – 0x90 Sep 06 '13 at 17:28
  • What does it mean that you can't "use perf with it"? The code in your module will get sampled when it executes. Do you need this feature you describe as a development tool occasionally or do you intend that your module should be able to interact with the perfcounters as a part of its normal operation? – Brian Cain Sep 06 '13 at 17:29
  • I issue I have 3 projects one is a kernel module and userland app I can compile with `-g` flag and perf will be able to sample it (not sure how to do it exactly but I know it is feasible), second thing I have a bare metal code which I need to use by myself the performance counters. the third one is to interact with the PMU within a dedicated kernel module. – 0x90 Sep 06 '13 at 17:34
  • 1
    **perf_event_v7.c** is for the Cortex series afaik. The **perf_event.c** and **perf_event_cpu.c** are probably infra-structure things. The other two files are for different CPUs (ARM11, XScale). Maybe you guessed that already? The ARMV7 manual has information in a chapter about the registers. I think you need this for your *bare metal* part. – artless noise Sep 06 '13 at 18:56
  • @artlessnoise any chance you format your comments and notes into an answer ? – 0x90 Sep 06 '13 at 19:17
  • 1
    I am guessing what you want. Mats already did a good job of answering the question as it stands. Try to search SO for [arm+pmu](http://stackoverflow.com/search?q=[arm]+pmu). There are good hits. Work through it and find some registers that you need more of a comment on. [This](http://stackoverflow.com/questions/3247373/how-to-measure-program-execution-time-in-arm-cortex-a8-processor) and [this](http://stackoverflow.com/questions/9795132/measure-executing-time-on-arm-cortex-a8-using-hardware-counter) also look helpful. – artless noise Sep 06 '13 at 20:12

2 Answers2

4

Perf_event does provide an API that can be used programmatically, but the documentation is sparse at best. Vince Weaver made the best resource for using the perf_event API here: http://web.eece.maine.edu/~vweaver/projects/perf_events/

He also provides some example code for recording counters.

However your best bet is to use an API that wraps perf_event and makes it more accessible, like PAPI (http://icl.cs.utk.edu/papi/)

EDIT: Since you want to do this from a kernel module, PAPI will not be available. The perf_event API still is, however.

Alfredo Gimenez
  • 2,174
  • 1
  • 14
  • 19
  • Am I missing something, or dose PAPI only work in user-mode? The original question is, at least partly "how to use this in a kernel driver". I think it is rather harsh to downvote my answer and then give a new answer that doesn't actually answer the original question. It's a free country, so you are alloowed to downvote my answer, but to have the courtesy to give a comment as to WHAT is wrong wouldn't go amiss. Also, providing an answer that actually covers the original question completely would probably be appreciated (even if it's a year and half after the question was originally asked) – Mats Petersson Mar 16 '15 at 20:47
  • I downvoted because you said perf_events is not meant to be used by a driver, when it in fact does provide an API, one that is accessible from both kernel-space and user-space. You're right that PAPI is user-space, so maybe that point was irrelevant given that the OP wants to use this in a kernel driver, and also I apologize for not previously justifying the downvote. Is there any reason why using the perf_event API isn't a complete answer to the question? – Alfredo Gimenez Mar 17 '15 at 21:41
  • 1
    Thanks for your reply. I dislike downvotes on old answers with no comment, because it doesn't teach the person writing the answer anything, and if I'm wrong, I want to know what I'm wrong about (and sometimes I have a feeling people downvote for no particular reason!) – Mats Petersson Mar 17 '15 at 22:27
1

The functionality in the perf_* files is used by/provided for tools like oprofile and perf tools.

And no, they are not ALWAYS available, as there is a config option (CONFIG_PERF_EVENTS) to enable/disable performance measurements.

The functionality is not really meant to be used from another driver. I'm pretty sure that will "upset" any user of oprofile or perf.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • See my reply to your above comment: in short, the functionality in the perf_* files is accessible through the perf_event API, which is available in user- and kernel-space, and the oprofile and perf tools are user-space programs, so won't help the OP do performance measurements in a module. – Alfredo Gimenez Mar 17 '15 at 21:43