[lkml]   [2011]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectHW perf initialisation as early_initcall
    Hi Peter,

    In commit 004417a6 ("perf, arch: Cleanup perf-pmu init vs lockup-detector"),
    you moved the arch hw perf initialisation into an early initcall to satisfy a
    race with the NMI lock detector (I'm not clear on what the relationship is).

    Anyway, with ARM big/little platforms on the horizon we have the fun of
    heterogeneous PMUs in the sense that:

    - They may have different numbers of event counters
    - They may support different event types (possibly a distinct set)
    - The event encodings for the generalised events may be different

    The latter two points I think can be solved in the back-end by making events
    affine to a particular PMU type (that is, they are only scheduled when the
    profiled task is running on a given PMU type), although I'm not sure how this
    will be exposed to userspace yet. It might be nice to register a separate
    PMU with perf altogether, but I don't think the userspace tools are there
    yet in terms of specifying the destination PMU for an event.

    The first point is part of a bigger problem, namely that we can only find
    out the PMU topology of the system by probing the device tree. For older
    platforms, we will still probe the PMU of the boot CPU by inspecting the ID

    My question is: does the hw perf initialisation really need to be an
    early_initcall and, if so, how much of the perf backend needs to be up and
    running? It may be that the early initcall assumes all PMUs are the same and
    then later on I go and rewrite things like the number of counters.

    Of course, any ideas regarding the above are more than welcome!



     \ /
      Last update: 2011-11-23 15:59    [W:0.019 / U:13.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site