[lkml]   [2009]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: II.2 - Event knowledge missing
    > 2/ Event knowledge missing
    > There are constraints on events in Intel processors. Different
    > constraints do exist on AMD64 processors, especially with
    > uncore-releated events.

    You raise the issue of uncore events in IV.1, but let us reply here

    Un-core counters and events seem to be somewhat un-interesting to
    us. (Patches from those who find them interesting are welcome of

    So they werent in the first line of PMU features to cherry-pick

    The main problem with uncore events is that they are per physical
    package, and hence tying a piece of physical metric exposed via them
    to a particular workload is hard - unless full-system analysis is
    performed. 'Task driven' metrics seem far more useful to performance
    analysis (and those are the preferred analysis method of most
    user-space developers), as they allow particularized sampling and
    allow the tight connection between workload and metric.

    If, despite our expecations, uncore events prove to be useful,
    popular and required elements of performance analysis, they can be
    supported in perfcounters via various levels:

    - a special raw ID range on x86, only to per CPU counters. The
    low-level implementation reserves the uncore PMCs, so overlapping
    allocation (and interaction between the cores via the MSRs) is
    not possible.

    - generic enumeration with full tooling support, time-sharing and
    the whole set of features. The low-level backend would time-share
    the resource between interested CPUs.

    There is no limitation in the perfcounters design that somehow makes
    uncore events harder to support. The uncore counters _themselves_
    are limited to begin with - so rich features cannot be offered on
    top of them.

    > In your model, those need to be taken care of by the kernel.
    > Should the kernel make the wrong decision, there would be no
    > work-around for user tools. Take the example I outlined just above
    > with Intel fixed counters.

    Yes. Why should there be a work-around for user tools if the fix is
    for the kernel? We don't try to work around random driver bugs in userspace
    either, we simply fix the kernel.

    > The current code-base does not have any constrained event support,
    > therefore bogus counts may be returned depending on the event
    > measured.

    Then we'll need to grow some when we run into them :-)

     \ /
      Last update: 2009-06-22 14:01    [W:0.023 / U:8.548 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site