Allow users to create and use custom PMU configurations #242
Conversation
Move to using JSON to hold the event details for Perf Stat. This makes it easier to modify the files without the need for interacting with the Rust compiler. This is also in preparation for allowing the user to specify a custom PMU config file.
|
We might want to consider carrying the custom PMU file , that a user may provide, in the run data. |
| @@ -0,0 +1,20 @@ | |||
| [ | |||
There was a problem hiding this comment.
I would suggest you have a CI job that validates each and every one of the .json configs in src/data/*.json. Don't have to collect any valid data, just make sure the files parse.
Probably worth providing a way for aperf to load the file and say "all good" without even trying to collect.
This is a good idea. We should probably put the used PMU config in the run data any time PMU data is collected (regardless of custom or not). rationale: PMU config can change between versions. |
Allow the user to specify a custom PMU file to be used during aperf record. This custom PMU file must be in the expected format. To aid in the creation of the custom PMU file, add a sub-command. 'aperf custom-pmu' - an interactive sub-command to create custom PMU. This allows the user to create a file from scratch or modify an existing PMU config aperf already knows about. The custom file generated can be used by specifying '--pmu-config' with 'aperf record'. Additionally, a pmu-config file can be verified by specifying --verify along with --pmu-file with 'aperf custom-pmu'.
We are now storing the PMU config used by aperf in the recorded data. This occurs irrespective of if the PMU config is user supplied or default. |
lrbison
left a comment
lrbison
left a comment
There was a problem hiding this comment.
some small nits, but LGTM. Thanks for addressing the others.
| { | ||
| "perf_type": "RAW", | ||
| "name": "Cycles", | ||
| "config": 17 |
There was a problem hiding this comment.
I just realized that all these numbers are in decimal because JSON doesn't support hex integers directly.
Unfortunately pretty much every PMU document ever will list counters in hex. This makes inspecting or editing these counters very painful because anything over than 0x20 becomes difficult to convert in my head.
What if we make config a string and then instead of "config": 17 we could write "config": "0x11".
There was a problem hiding this comment.
Yeah. That's an improvement we can consider.
| "name": "stall_backend_pkc", | ||
| "nrs": [ | ||
| { | ||
| "perf_type": "RAW", |
There was a problem hiding this comment.
Best I can tell, "perf_type": "RAW" can be inferred by the presence of the "config" field. Everything is either raw or has nrs.
There was a problem hiding this comment.
RAW here indicates CPU. We're looking to add support for other types of PMUs too which the perf_type will hold.
2 participants
Currently, Aperf collects data from a set of pre-configured PMU events. The user has no way of collecting custom PMU events.
This PR includes two changes.
aperf custom-pmuwhich will allow the user to create/modify a custom PMU file which can then be passed in toaperf record. This file will replace the default for that platform.The uploaded aperf run had only 4 events collected. The
aperf custom-pmutool was used to modify the existing config.aperf_report_custompmu.tar.gz
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.