lkml.org 
[lkml]   [2010]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs
    From
    Date
    On Mon, 2010-05-10 at 16:13 -0700, Corey Ashford wrote:

    > Having extra fields for each event would allow us to describe hardware-specific event attributes. For example:
    > /sys/devices/system/node/nodeN/node_events
    > node_events/event_source_id
    > node_events/local_misses/event_id
    > /local_hits/event_id
    > /crypto_datamover <- specific node PMU
    > /marked_crb_rcv_des
    > /event_id
    > /attrib
    > /lpid <- attribute name
    > /lpid/type <- type of attribute (boolean, integer, etc.)
    > /lpid/min <- min value of int attribute
    > /lpid/max <- max value of int attribute
    > /lpid/bit_offset <- amount to shift attribute value before OR'ing into the raw event code
    > /marking_mode <- attribute name
    > /marking_mode/type
    > /...
    >
    > Of course, these nodes would need to be replicated for each event that needs them or other attributes.

    I would suggest having a 1:n pmu:event_source ratio, not the other way
    around. So in your example above the crypto_datamover PMU thingy would
    get its own event_source(s), which get placed at whatever place in the
    machine topology they live. If that happens to be at the node level,
    place them there.

    > >> Sure, sounds like a sensible suggestion.
    > >>
    > >> One thing I'd also like to clarify is that !raw events should not be
    > >> exhaustive hardware event lists, those are best left for userspace, but
    > >> instead are generally useful events that can be expected to be implemented
    > >> by any hardware of that particular class.
    >
    > Why exactly is this? I got the impression this was something you and
    > Ingo wanted earlier. As big of an impact as it will be, it would be
    > nice to unify the two event spaces (generic and raw) into one space
    > that can be explored by a user space tool (or even crudely
    > by /bin/ls).

    No we want generic event spaces that have events that are generally
    applicable to a whole class of PMUs, so say to all CPU PMUs, or all GPU
    PMUs or all PCI-bridge PMUs.

    What we do not want are exhaustive event lists for specific PMU
    implementations, those are best left for userspace.

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

    \
     
     \ /
      Last update: 2010-05-12 10:15    [W:0.022 / U:90.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site