Re: [perfmon2] IV.3 - AMD IBS

From: Ingo Molnar
Date: Tue Jun 23 2009 - 10:06:25 EST



* stephane eranian <eranian@xxxxxxxxxxxxxx> 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)

No extra sampling, no extra events - just a transparent side channel
implementation for the specific case of PERF_COUNT_HW_CPU_CYCLES. (A
bit like the fixed-purpose counters are done on the Intel side - a
special-case - but none of the generic code knows about it.)

This gives us immediate results with less code, and also gives us
the platform to see how IBS is structured, what kind of general
problems/quirks it has, and how popular its precision is, etc. We
can always add extra sampling formats on top of that (i'm not
opposed to that), to expose more and more of IBS.

The same can be done on the PEBS side as well.

Would you be interested in pursuing this?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/