lkml.org 
[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [perfmon2] IV.3 - AMD IBS
    From
    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.


    \
     
     \ /
      Last update: 2009-06-23 10:23    [W:3.384 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site