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
commit9a91f00699d770ff7bd0e9aa4ecee1533351b41c (patch)
tree1751083cd49dc782f9e74d8509332734e90e02c9
parentb5208340baa5896ce9f69081b1ead30f20e85b9a (diff)
downloadarchsetup-9a91f00699d770ff7bd0e9aa4ecee1533351b41c.tar.gz
archsetup-9a91f00699d770ff7bd0e9aa4ecee1533351b41c.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~