Messages in this thread | | | Date | Tue, 23 Jun 2009 10:19:12 +0200 | Subject | Re: [perfmon2] IV.3 - AMD IBS | From | stephane eranian <> |
| |
On Tue, Jun 23, 2009 at 8:19 AM, Peter Zijlstra<a.p.zijlstra@chello.nl> wrote: > > The 'problem' I have with IBS is that its basically a cycle counter > coupled with a pretty arbitrary number of output dimensions separated > into two groups, ops and fetches. > Well, that's your view. Mine is different.
You have 2 independent cycle counters (one for fetch, one for op), each is coupled with a value. it is just that the value does not fit into 64 bits. the cycle count is not hosted in a generic counter but in its own register. The captured data for fetch is constructed with IBSFETCHCTL, IBSFETCHLINAD, IBSFETCHPHYSAD. The 3 registers are tied together. The values they contain represent the same fetch event. Same thing with IBS op. I don't see the problem because your API is able to cope with variable length output data. The sampling buffer certainly can. Of course, internally you'd have to manage it in a special way, but you already do this for fixed counters, don't you?
> This is a very weird configuration in that it has a miss-match with the > traditional one value per counter thing. > This is not the universal model. I can give lots of examples on Itanium where you have one config register and multiple data registers to capture the event: branch trace buffer (1 config, 33 data), Data EAR (cache/TLB miss sampling, 1 config 3 data),Instruction-EAR (cache/TLB miss sampling, 1 config, 2 data).
> 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.
What is wrong with this approach?
Another question is: how do you present the values contained in the IBS data registers: 1 - leave it as raw (tool parses the raw register values) 2 - decode it in the kernel and expose your own format
With 1/, you'd pick up automatically new fields if AMD adds some. With 2/, you'd have to change your format if AMD change theirs.
> This is however quite cumbersome. > > One thing to consider when building an IBS interface is its future > extensibility. In which fashion would IBS be extended?, additional > output dimensions or something else all-together? > I don't know but it would be nice to provide better filtering capabilities but for that, they can use some of the reserved bits they have, no need to add more data registers.
| |