fix: stop messing with C-states in performance tests

When running performance tests, the devtool script was disabling lower
C-states, leaving only C0 (e.g. "CPU actively polling for new
instructions") enabled, with the goal to reduce latencies of switching
between C-states, and therefore increase test stability. However, we
found out that on m6i (Icelake) this was causing performance to become
erratic, with most performance metrics taking on bi-modal
characteristics.

Since back when we originally disabled sleep states, we did not see any
impact on metrics, the theory that it helps with test stability doesn't
have any experimental support, so removing the C-state configuration to
fix the volatility on m6i is not expected to have any drawbacks.

Signed-off-by: Patrick Roy <[email protected]>

Author: roypat

tools/devtool

@@ -630,11 +630,10 @@ apply_linux_61_tweaks() {
 }
 
 
-# Modifies the processors C- and P-state configuration (x86_64 only) for consistent performance. This means
+# Modifies the processors CPU governor and P-state configuration (x86_64 only) for consistent performance. This means
 # - Disable turbo boost (Intel only) by writing 1 to /sys/devices/system/cpu/intel_pstate/no_turbo
 # - Disable turbo boost (AMD only) by writing 0 to /sys/devices/system/cpu/cpufreq/boost
 # - Lock the CPUs' P-state to the highest non-turbo one (Intel only) by writing 100 to /sys/devices/system/cpu/intel_pstate/{min,max}_perf_pct
-# - Disable all idle C-states, meaning all CPu cores will idle by polling (busy looping) by writing 1 to /sys/devices/system/cpu/cpu*/cpuidle/state*/disable
 # - Set the cpu frequency governor to performance by writing "performance" to /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
 apply_performance_tweaks() {
   # m6a instances do not support the amd_pstate driver (yet), so nothing we can do there
@@ -660,15 +659,6 @@ apply_performance_tweaks() {
   # their maximum safe frequency. It seems to be the default for Amazon Linux, but it doesn't hurt to make this explicit.
   # See also https://wiki.archlinux.org/title/CPU_frequency_scaling
   echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor &> /dev/null
-
-  # When a CPU core has nothing to do, it enters an idle state, also called "C-state". These are enumerated, with C0
-  # being the shallowest idle state (corresponding to "currently executing instructions", aka "not actually idling"),
-  # and higher numbers being deeper sleep states (how many there are depends on the specific processor). The deeper
-  # a C-state a CPU core enters, the higher the latency to wake it up again. We can disable deeper C-states altogether
-  # by forcing each CPU core to constantly stay in C-0 (e.g. have them actively poll for new things to do).
-  # See also https://www.kernel.org/doc/html/v5.0/admin-guide/pm/cpuidle.html.
-  # The below also set "disable=1" on "state0", but this does not do anything (as disabling C-0 makes no sense).
-  echo 1 |sudo tee /sys/devices/system/cpu/cpu*/cpuidle/state*/disable &> /dev/null
 }
 
 unapply_performance_tweaks() {
@@ -683,9 +673,6 @@ unapply_performance_tweaks() {
     echo 1 | sudo tee /sys/devices/system/cpu/cpufreq/boost &> /dev/null
   fi
 
-  # reenable deeper sleep states
-  echo 0 | sudo tee /sys/devices/system/cpu/cpu*/cpuidle/state*/disable &>/dev/null
-
   # We do not reset the governor, as keeping track of each CPUs configured governor is not trivial here. On our CI
   # instances, the performance governor is current the default anyway (2023/11/14)
 }