papi framework: Do not allow events to be added without the component or pmu prefix names unless applicable

[Treece-Burgess]

Pull Request Description

Issue:
Currently in the master branch, users are able to add native events without their component prefix name. For example, the component appio contains an event READ_BYTES and can still successfully be added if it lacks the component prefix name appio::::

[ICL:methane bin]$ ./papi_command_line READ_BYTES

This utility lets you add events from the command line interface to see if they work.

Successfully added: READ_BYTES

READ_BYTES : 	0 

----------------------------------

This behavior is undesired as:

1. Native event output from papi_native_avail does show the applicable component or pmu prefix names
2. Multiple components could have the same native event if you takeaway the component or pmu prefix names
   • This was observed recently with the appio and io components

This PR resolves this behavior and closes Issue #526.

Testing

Testing Setup

Testing was done on Methane at ICL with:

• CPU: Intel Xeon Gold 6140
• GPU: 1 * NVIDIA A100
• OS: Rocky Linux 9.6

Testing Results

• PAPI build: ✅
• PAPI utilities*: ✅
• appio component tests after adding appio::: to hardcoded event names: ✅
• example component tests after adding example::: to hardcoded event names: ✅

Output from papi_command_line

[ICL:methane bin]$ ./papi_command_line BACLEARS

This utility lets you add events from the command line interface to see if they work.

Successfully added: BACLEARS

BACLEARS : 	80 

----------------------------------

[ICL:methane bin]$ ./papi_command_line READ_BYTES

This utility lets you add events from the command line interface to see if they work.

Failed adding: READ_BYTES
because: Event does not exist
No events specified!
Try running something like: ./papi_command_line PAPI_TOT_CYC

* - papi_component_avail, papi_native_avail, papi_command_line

Author Checklist

• Description
  Why this PR exists. Reference all relevant information, including background, issues, test failures, etc
• Commits
  Commits are self contained and only do one thing
  Commits have a header of the form: module: short description
  Commits have a body (whenever relevant) containing a detailed description of the addressed problem and its solution
• Tests
  The PR needs to pass all the tests

[dbarry9]

I am reviewing this PR.

[dbarry9]

I tested these changes on the Frontier supercomputer, which contains the AMD Zen3 CPU and AMD MI250X GPU architectures using ROCm 7.0.2. The PAPI utilities (papi_avail, papi_native_avail, papi_component_avail, papi_hardware_avail, and papi_mem_info) and the amd_smi, appio, example, rocm, rocm_smi, rocp_sdk, and sde component tests behave as expected. I did notice that the desired changes are reflected in the applicable component tests, such as the following:

< 0x40000014 appio:::READ_BYTES = 614
---
> 0x40000014 READ_BYTES = 614

@Treece-Burgess Can you please address my other review comments and rebase? After you do, I will approve this PR, and we can merge it. Thank you!

[dbarry9]

I am testing the latest commit.

[dbarry9]

Testing this on Frontier with (AMD Zen3 CPU architecture), I confirm that the latest commit results in proper behavior for PMU prefixes:

$> papi_command_line perf::CYCLES

This utility lets you add events from the command line interface to see if they work.

Successfully added: perf::CYCLES

perf::CYCLES :  240195072

----------------------------------
$> papi_command_line CYCLES

This utility lets you add events from the command line interface to see if they work.

Failed adding: CYCLES
because: Event does not exist
No events specified!
Try running something like: papi_command_line PAPI_TOT_CYC

In addition, the "default" PMU is still allowed for the applicable native perf_event events:

$> papi_command_line "UOPS_QUEUE_EMPTY"

This utility lets you add events from the command line interface to see if they work.

Successfully added: UOPS_QUEUE_EMPTY

UOPS_QUEUE_EMPTY :      5413

----------------------------------
$> papi_command_line "amd64_fam19h_zen3::UOPS_QUEUE_EMPTY"

This utility lets you add events from the command line interface to see if they work.

Successfully added: amd64_fam19h_zen3::UOPS_QUEUE_EMPTY

amd64_fam19h_zen3::UOPS_QUEUE_EMPTY :   5125

----------------------------------

@jagode Since this PR introduces a change (albeit small) to the perf_event component's source, could you please review it?

[Treece-Burgess]

Hello @deater, could you take a look at the change I made in perf_event/pe_libpfm4_events.c for this PR? Specifically I added the following block of code:

if ( (event_table->default_pmu.name) && (strcmp(pinfo.name, event_table->default_pmu.name) ) != 0 && (strcmp(pinfo.name, pmu_name) != 0)) {
    SUBDBG("EXIT: The provided event %s lacks the necessary pmu prefix %s.\n", name, pinfo.name);
    return NULL;
}

As an overview of this change, users will need to add native events for the perf_event component based off how they appear in the output for papi_native_avail. As an example, if perf::CYCLES is present in the output for papi_native_avail, but CYCLES is not then attempting to add just CYCLES will now not be successful. The pmu perf:: would need to be appended for a successful add.

[deater]

I think this is probably a good change, but it is possible it might break people's existing code that depends on the old behavior. I don't know if we'd need a more serious version bump because of that?

Related is the issue with the perf component where it has traditionally had the idea of the "default" component (which typically is the cpu component) and you don't need a prefix for events like that. Your changeset here doesn't seem to change that. This is a case where if we forced even the default component to have a prefix it would make things like handling hybrid CPUs a lot easier, however it might break a lot more people's code and require updating the papi_events.csv file, etc

[Treece-Burgess]

@deater

I think this is probably a good change, but it is possible it might break people's existing code that depends on the old behavior. I don't know if we'd need a more serious version bump because of that?

We internally consider the old behavior as a bug rather than a feature. However, I do know this old behavior has been in the codebase for a while and agree that it most likely will result in some users code possibly breaking. The next release for PAPI will be 7.3.0, by a more serious bump do you mean going up to 8.0.0?

Related is the issue with the perf component where it has traditionally had the idea of the "default" component (which typically is the cpu component) and you don't need a prefix for events like that. Your changeset here doesn't seem to change that. This is a case where if we forced even the default component to have a prefix it would make things like handling hybrid CPUs a lot easier, however it might break a lot more people's code and require updating the papi_events.csv file, etc

Correct, this PR does not change the behavior of the "default" component cases such as BACLEARS. If changing the "default" component to require a prefix would help with handling hybrid CPUs easier then it could be worth looking into and I can create an issue for it. Again, I agree that this change would result in breaking more user's code and that we would need to thoroughly update papi_events.csv.

[deater]

I don't have a good feel for if this is a big enough break to bump to 8.0 If we were bumping to 8.0 I'd suggest we break some other things at the same time, such as maybe getting rid of the default component.

We can probably get rid of default component in steps, maybe just always show the component in papi_native_avail at first but then still handle the lack of component for backwards compat? Things get complicated because technically all of the CPU events (core and uncore) are technically perf events handled by the perf component but it would be a bit much to ask them to have events like perf::hsw_ep::instructions or whatever.