aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-05-26 20:14:30 -0500
committerCraig Jennings <c@cjennings.net>2026-05-26 20:14:30 -0500
commitb6c09da5c3d85abfc3897ae722045a771f3b281a (patch)
tree527fc76b08d941a988197030bd2cc42f374f8f95
parent2453f0eb22d993fd483869b78ca163e0d30f12ac (diff)
downloadarchsetup-b6c09da5c3d85abfc3897ae722045a771f3b281a.tar.gz
archsetup-b6c09da5c3d85abfc3897ae722045a771f3b281a.zip
fix(archsetup): remove the cpupower setup, wrong for this hardware
I added cpupower earlier this session, VM-verified it, then realized it's the wrong tool here. Both my machines run active-mode pstate drivers (the desktop on amd-pstate-epp, the laptop on intel_pstate), where the only governors are performance and powersave and the driver scales frequency itself via EPP. Both already sit on powersave, which is the recommended adaptive mode, not "slow." cpupower's governor-forcing only helps older acpi-cpufreq systems, which I don't run. Forcing performance would pin max clocks: worse battery on the laptop, pointless heat on the desktop. So I dropped the cpupower step rather than ship a backwards default. The cpufreq drivers self-manage with no help from us.
-rwxr-xr-xarchsetup14
-rw-r--r--todo.org5
2 files changed, 4 insertions, 15 deletions
diff --git a/archsetup b/archsetup
index ce8117e..ae6d676 100755
--- a/archsetup
+++ b/archsetup
@@ -1232,20 +1232,6 @@ EOF
action="enabling upower service" && display "task" "$action"
systemctl enable upower >> "$logfile" 2>&1 || error_warn "$action" "$?"
- # cpupower applies a CPU frequency governor at boot from /etc/default/cpupower.
- # The cpupower package no longer ships that file, so write it fresh rather than
- # edit it. 'performance' is valid under every cpufreq driver -- amd_pstate and
- # intel_pstate active mode accept only performance and powersave, while
- # passive/acpi-cpufreq also allow schedutil/ondemand. Laptops (velox) want
- # 'powersave', a per-host override candidate. Non-fatal: an unsupported
- # governor just fails to apply at boot.
- pacman_install cpupower
- action="setting cpupower governor to performance" && display "task" "$action"
- printf "# Set by archsetup.\ngovernor='performance'\n" > /etc/default/cpupower 2>> "$logfile" || \
- error_warn "$action" "$?"
- action="enabling cpupower service" && display "task" "$action"
- systemctl enable cpupower.service >> "$logfile" 2>&1 || error_warn "$action" "$?"
-
# Secure Shell
display "subtitle" "Secure Shell"
diff --git a/todo.org b/todo.org
index 0c2ded3..3ff44db 100644
--- a/todo.org
+++ b/todo.org
@@ -873,7 +873,10 @@ Enhance existing indicators to show what's happening in real-time
** TODO [#D] Add retry logic to git_install function :quick:
pacman_install and aur_install have retry logic, but git_install doesn't
-** TODO [#D] Add cpupower installation and enabling to archsetup :quick:
+** CANCELLED [#D] Add cpupower installation and enabling to archsetup :quick:
+CLOSED: [2026-05-26 Tue]
+Implemented, VM-verified, then removed — wrong tool for this fleet. Both machines run active-mode pstate drivers (ratio amd-pstate-epp, velox intel_pstate) where only performance/powersave exist and the driver self-manages frequency via EPP; both correctly sit on powersave. cpupower's governor-forcing only helps older acpi-cpufreq systems, which we don't run. Forcing performance would pin max clocks (worse on the laptop, pointless on the desktop). Dropped from archsetup rather than ship a backwards default.
+
cpupower service configures the default CPU scheduler (powersave or performance)
Install cpupower, configure /etc/default/cpupower, enable service: ~systemctl enable --now cpupower.service~