Intel performance monitoring program under Linux

[edisonying1984]

Hi all,
I am a newbie to Osdev forum. I'm not sure if this is the correct subforum to post this thread; if not, please forward it to the correct place.

I am working on a project using hardware performance monitoring counters to analyze applications running on an Intel CPU. The operating system is Fedora 13 with kernel 2.6.33. In my current implementation, the counter values are read through a file under /proc (thus I need to create a proc_entry before the sampling and write the values to this file during execution), and the samplings are implemented by inserting a task into the delayed work queue (queue_delayed_work_on). By doing this, I am able to read the performance counter values at fixed time intervals, say, once a second.

However, I want to read the counters in another way. Namely, rather than collect those counters every second, I would like to read them after every one million instructions are executed. That is, read the counter values when 1M, 2M, 3M....instructions are executed. I have no clue on this change.

Can anyone give me a hint on this? Any suggestions will be appreciated.

Thanks

[Love4Boobies]

I'm afraid you cannot unless you write a small x86 interpreter (which will obviously have some overhead). Even then you will have problems with self-modifying code; if you wish to support that, you'll need to turn your project into a JIT interpreter.

[Brendan]

Hi,

For some CPUs it is possible to configure one of the counters to count "instructions retired" and generate an interrupt (via. the local APIC) when its counter overflows, and set the initial count to "MAX - 1 million" so you get the IRQ after 1 million instructions. Then it'd be a matter of polling the other counters during this "1 million instructions" IRQ.

The main problem is that performance monitoring is very messy (it's all "model specific"); and this can't work on some CPUs (e.g. Pentium where there's no "interrupt on overflow" ability), and can make it impossible to measure some types of events on some CPUs (where you have to use specific counters for certain events, you won't be able to count events that require the counter that's already used for "instructions retired").

The other main problem is that the kernel is Linux - you don't have free reign, and you have to try your hardest to make sure you don't break compatibility or other features, and at the end of the day the kernel maintainers will refuse to accept the patch for any number of unpredictable reasons..


Cheers,

Brendan