-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow users to create and use custom PMU configurations #242
base: main
Are you sure you want to change the base?
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.
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'.
We might want to consider carrying the custom PMU file , that a user may provide, in the run data. |
let user_provided_list: Vec<NamedCtr> = serde_json::from_reader(&f)?; | ||
if user_provided_list.is_empty() { | ||
error!( | ||
"User provided PMU configuration is invalid. Falling back to default events." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't fall back. This should be a fatal error and an abort.
#[cfg(target_arch = "aarch64")] | ||
use crate::data::grv_perf_events; | ||
pub mod arm64_perf_list { | ||
pub static GRV_EVENTS: &[u8] = include_bytes!("grv_perf_list.json"); | ||
} | ||
#[cfg(any(target_arch = "x86", target_arch = "x86_64"))] | ||
use { | ||
crate::data::{ | ||
amd_genoa_perf_events::GENOA_CTRS, amd_milan_perf_events::MILAN_CTRS, amd_perf_events, | ||
intel_icelake_perf_events::ICX_CTRS, intel_perf_events, | ||
intel_sapphire_rapids_perf_events::SPR_CTRS, utils::get_cpu_info, | ||
}, | ||
indexmap::IndexMap, | ||
}; | ||
pub mod x86_perf_list { | ||
/// Intel+ events. | ||
pub static INTEL_EVENTS: &[u8] = include_bytes!("intel_perf_list.json"); | ||
pub static ICX_CTRS: &[u8] = include_bytes!("intel_icelake_ctrs.json"); | ||
pub static SPR_CTRS: &[u8] = include_bytes!("intel_sapphire_rapids_ctrs.json"); | ||
|
||
/// AMD+ events. | ||
pub static AMD_EVENTS: &[u8] = include_bytes!("amd_perf_list.json"); | ||
pub static GENOA_CTRS: &[u8] = include_bytes!("amd_genoa_ctrs.json"); | ||
pub static MILAN_CTRS: &[u8] = include_bytes!("amd_milan_ctrs.json"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the difference in name between "Events" and "Counters" here? Is now a good time to get rid of that?
"Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz" => ICX_CTRS.to_vec(), | ||
"Intel(R) Xeon(R) Platinum 8488C" => SPR_CTRS.to_vec(), | ||
_ => Vec::new(), | ||
"Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz" => x86_perf_list::ICX_CTRS, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated to this change I realize, but the @ 2.90GHz seems needlessly precise.
@@ -0,0 +1,20 @@ | |||
[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
} | ||
} | ||
|
||
pub fn modify_existing_config(cpmu: &CustomPMU) -> Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I don't think anyone will be using this input method. Just ask them to use a text editor and provide documentation on the format. I'd suggest deleting the modification routines, but I would suggest keeping the ability to dump what would be collected to a file for the user to modify.
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. |
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-pmu
which 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-pmu
tool 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.