Configure | run_test.sh : Disable perf_event and perf_event_uncore

[djwoun]

Pull Request Description

--disable-perf-event-uncore Disable perf_event_uncore component
--disable-perf-event Disable perf_event component(disabling perf_event will disable perf_event_uncore as well)
--disable-cpu Disable perf_event and perf_event_uncore component

configure/configure.in

• Added --disable-cpu, --disable-perf-event, --disable-perf-event-uncore.
• Disabled sysdetect if perf-event is disabled
• Changed AC_MSG_ERROR → AC_MSG_RESULT.
• added awk statements to comment ctest/ftest/vtest in Makefile.inc.
• Reinstates them if disabling CPU is not specified.
• Changed a condition for enabling perf_events on for "if eval test "x$"$as_ac_File"" = x"yes"; then :"

Run_tests.sh

• Checks for perf_event.
• If not enabled, ctests ftests vtests do not run.

Darwin-common.h

• Retrieve the current thread's ID using pthread_self(), but instead of returning the pthread_t value directly, it copies the memory of the pthread_t into a pid_t variable and returns it.
• Added missing library: #include <pthread.h>.

Darwin-common.c & darwin-memory.c

• Added missing library: #include <sys/sysctl.h>.

threads.c

• macOS-specific thread ID function.

Print_header.c

• Checks if perf_event is missing and returns "NA" if it isn’t present.
• Displays: Number of Hardware Counters : PAPI error -1: Invalid argument.
  • This only happens for ROCm.
  • Says "NA" for ROCm.
  • Else: displays 0 or the number of hardware counters of other devices.
  • If there are no components enabled, options is null. This results in the last print statement to segfault, so now it checks if the options variable is NULL.
  • When there are 0 components. Max Multiplex Counters : PAPI error -4: Not supported by component

CUDA Support

• Nvidia stopped supporting cuda for macos

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

[jagode]

In configure, I'm not sure where "as_fn_result" originates from. If I rerun autoconf on configure.in, it disappears and configure works fine. However, without it, I receive the following error:

checking for timer_create and timer_*ettime symbols in -lrt -lpthread... ./configure: line 4463: as_fn_result: command not found

Since we need to regenerate the configure file anyway, could you please make the following change to line 232 in configure.in before rerunning autoconf?:

diff --git a/src/configure.in b/src/configure.in
index 53f3dd63..c04fa823 100644
--- a/src/configure.in
+++ b/src/configure.in
@@ -232,7 +232,7 @@ else
                         AC_MSG_RESULT([found])
                         LRT="-lrt -lpthread"
                 else
-                       AC_MSG_RESULT([cannot find timer_create and timer_*ettime symbols neither in the base system libraries nor in -lrt, nor in -lrt -lpthread])
+                       AC_MSG_RESULT([not found])
                fi
        fi
 fi

[djwoun]

Components would get configured even if the user provided an empty "--with-components="". Daniel and I figured out a new check to ensure that the component would only be configured when there wouldn't be an empty string.

This problem didn't appear in gcc 11.4 but did in 12.2.1.

[Treece-Burgess]

If a user is on a machine that has insufficient permissions, upon running ./configure the following block of text will output:

configure: WARNING: 

***************************************************************************
* Insufficient permissions for accessing any hardware counters.           *
* Your current paranoid level is 4.                                       *
* Set /proc/sys/kernel/perf_event_paranoid to 2 (or less) or run as root. *
*                                                                         *
* Example:                                                                *
* sudo sh -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"              *
***************************************************************************

If a user is on a machine with insufficient permissions, but uses --disable-cpu or --disable-perf-eventdo we still want to print out the above message during the configure stage?

[djwoun]

If a user is on a machine that has insufficient permissions, upon running ./configure the following block of text will output:

configure: WARNING: 

***************************************************************************
* Insufficient permissions for accessing any hardware counters.           *
* Your current paranoid level is 4.                                       *
* Set /proc/sys/kernel/perf_event_paranoid to 2 (or less) or run as root. *
*                                                                         *
* Example:                                                                *
* sudo sh -c "echo 2 > /proc/sys/kernel/perf_event_paranoid"              *
***************************************************************************

If a user is on a machine with insufficient permissions, but uses --disable-cpu or --disable-perf-eventdo we still want to print out the above message during the configure stage?

Assuming that users would need perf_event_paranoid set to 2 (or less) or to run as root to access hardware counters beyond the CPU, I believe we should still print out the above message during the configure stage.

[dbarry9]

These changes function properly, as tested using the PAPI utilities and the run_tests.sh script on IBM POWER10, AMD Zen2 + NVIDIA A100, and Intel Sapphire Rapids + NVIDIA RTX-A2000 systems.

[Treece-Burgess]

I further tested to see if the component index shifted properly when compiling in another component (e.g. cuda) and using one of the provided flags: --disable-perf-event-uncore, --disable-perf-event, and --disable-cpu.

Both PAPI_get_component_index and PAPI_get_component_info showed the proper index.