Messages in this thread | | | Date | Tue, 23 Jun 2009 16:55:08 +0200 | From | Ingo Molnar <> | Subject | Re: [perfmon2] IV.3 - AMD IBS |
| |
* stephane eranian <eranian@googlemail.com> wrote:
> On Tue, Jun 23, 2009 at 4:05 PM, Ingo Molnar<mingo@elte.hu> wrote: > > > > * stephane eranian <eranian@googlemail.com> wrote: > > > >> > The most natural way to support IBS would be to have a special > >> > sampling cycle counter and use that as group lead and add non > >> > sampling siblings to that group to get individual elements. > >> > > >> As discussed in my message, I think the way to support IBS is to > >> create two pseudo-events (like your perf_hw_event_ids), one for > >> fetch and one for op (because they could be measured > >> simultaneously). The sample_period field would be used to express > >> the IBS*CTL maxcnt, subject to the verification that the bottom 4 > >> bits must be 0. And then, you add two new sampling formats > >> PERF_SAMPLE_IBSFETCH, PERF_SAMPLE_IBSOP. Those would only work > >> with IBS pseudo events. Once you have the randomize option in > >> perf_counter_attr, you could even enable IBSFETCH randomization. > > > > I'd suggest to start smaller, and first express the 'precise' > > nature of IBS transparently, by simply mapping it to one of the > > generic events. (cycles and instructions both appears to be > > possible) > > IBS is precise by nature.
(yes. Did you understand my comments above as saying the opposite?)
> [...] It does not work like PEBS. It tags an instruction and then > collects info about it. When it retires, IBS freezes and triggers > an interrupt like a regular counter interrupt. Except this time, > you don't care about the interrupted IP, you use the instruction > address in the IBS data register, it is guaranteed to correspond > to the tagged instruction. > > The sampling period expresses the delay before picking the > instruction to tag. And as I said before, it is only 20 bits and > the bottom 4 bits must be zero (as they cannot be encoded).
The 20 bits delay is in cycles, right? So this in itself still lends itself to be transparently provided as a PERF_COUNT_HW_CPU_CYCLES counter.
Ingo
| |