Not sure I'm fully understanding.With the sysfs layout we'd have to
{
"MetricExpr": "pmu_unit@event_foo@ * pmu_unit@event_bar@ * 2",
"MetricName": "metric_baz",
},
{
"EventCode": "0x84",
"EventName": "event_foo ",
"Compat": "0x00000040",
"Unit": "pmu_unit"
},
{
"EventCode": "0x85",
"EventName": "event_bar ",
"Compat": "0x00000040",
"Unit": "pmu_unit"
},
And we have a pmu with name and hw id matching "pmu_unit" and
"0x00000040" present, that we select metric metric_baz for soc_b
have a way of supporting CPUIDs, we could have a mapfile.csv style
approach or perhaps encode the CPUID into the path. It is complex as
CPUIDs are wildcards in the tool.
When I get a chance 😄 My thought is to first extend jevents.py toI think Unit may be useful, say on IntelDo you have an RFC or something for this "sysfs style layout"? I think
hybrid I want the tma_fround_bound metric on just cpu_atom. Currently
the use of Unit is messy for metrics, ie uncore metrics are associated
with core PMUs, and what to do with a MetricExpr with >1 PMU. I think
we're learning from trying. I'm just hoping the migration to a sysfs
style layout will still be possible, as I can see lots of upside in
terms of testing, 1 approach, etc.
that it would be easier for me to understand your idea by seeing the SW.
have a second output format, so sysfs style rather than pmu-events.c.
This way we can merge the changes as a jevents.py feature even if we
don't change the perf tool to support it.