I'm considering adding ProfileMe support for Alpha EV67, and I'm
wondering how to implement it within the oprofile framework.
ProfileMe works like this: A counter counts down cycles. When it
reaches zero, a current instruction is picked, and several conditions
are recorded. When the instruction retires, a trap is executed, and
the kernel can examine the instruction and its properties. That way,
one can know exactly what instruction caused an event.
Lots of properties can be queried, but I would like to cut it down to
* Stalled for at least one cycle between the fetch and map stages
* Conditional branch taken
* Branch caused mispredict trap
* ITB miss
* DTB miss
* Replay trap
* Load-store order trap
* Icache miss
* Unaligned Load/Store
On the Alpha EV67, there are actually two counters that can be used to
trigger ProfileMe interrupts. They can count cycles, retired
instructions, cycles of delayed retire pointer advance, or Bcache
misses (only some combinations are valid).
So the idea was to introduce an additional 18 fake counters, one for
each combination of counter and ProfileMe property. The interrupt
handler would determine the properties given for the instruction, and
increment the appropriate counter. Does that sound like a good idea?
For example, I could then set counter 0 to count cycles (or
instructions, doesn't really matter), and enable the "taken" and
"mispredict" counters that depend on counter 0 to get nice statistics
about branches, which could probably be pretty-printed by op_to_source
/* 12345 0.001% taken 95.2% mispredict 1.2% */
bne t0, label
Or is there an easier way to model it?
From: John Levon <levon@mo...> - 2003-01-12 22:58:50
On Sun, Jan 12, 2003 at 06:03:55PM +0100, Falk Hueffner wrote:
> I'm considering adding ProfileMe support for Alpha EV67, and I'm
> wondering how to implement it within the oprofile framework.
From your description, the method you propose sounds reasonable to me.