Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

janaknat
Copy link
Contributor

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.

  1. Move the pre-configured PMU events to a JSON file format.
  2. Create a subtool aperf custom-pmu which will allow the user to create/modify a custom PMU file which can then be passed in to aperf record. This file will replace the default for that platform.
  • The user has the option to:
    • create a custom PMU file from scratch
    • modify (add, delete) existing pre-defined defaults
    • update (add, delete) a custom PMU file

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.

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'.
@janaknat janaknat requested a review from a team as a code owner December 26, 2024 19:54
@janaknat
Copy link
Contributor Author

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."
Copy link
Contributor

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.

Comment on lines 16 to +31
#[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");
}
Copy link
Contributor

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,
Copy link
Contributor

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 @@
[
Copy link
Contributor

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<()> {
Copy link
Contributor

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.

@lrbison
Copy link
Contributor

lrbison commented Jan 7, 2025

We might want to consider carrying the custom PMU file , that a user may provide, in the run data.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants