Yup ; I just compiled and installed. I stared to make an rpm against the upstream fedora src and it became annoying because it’s tagged as a named version in the tarball vs numbered and I would have had to make a diff patch.
It’s based on the 0.13 in fedora anyway.
It looks like edits are only allowed for a few days, so pardon the new post.
Config & methodology as outlined above.
Test 4. synopsis above.
tlp.conf min adjustments per above and with the following changes:
CPU_SCALING_GOVERNOR_ON_BAT=conservative
CPU_BOOST_ON_BAT=0
10% use took 0:51 for avg draw of 6.47W
TLP same conf with amdpstate status = guided
after setting smt to off, no appreciable gains were observed. In fact, this could be deleterious as cpu load is spread over a smaller pool.
Reran some tests without powertop and didn’t observe differences in run times.
Conclusions
To Do
tlp.conf diff with any add’l efficienciestuned as it develops
In case the commands used during testing may be helpful to some folks:
a) current cpu power management config
cpupower frequency-info : as well as other options, see manpage. When amd pstate is active, this will include output of:
driver: amd-pstate-epp
b) check current amd_pstate status (if not found, amd pstate may not be active):
cat /sys/devices/system/cpu/amd_pstate/status
c) see which scaling governor is in use:
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
Note: changing policy0 to policy* will show all cpus/threads. For instance, to specify an alternate governor:
echo 'ondemand' | sudo tee /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
d) see current energy performance preference setting:
cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference
e) see available energy performance options:
cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_available_preferences
f) review min/max cpu settings:
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m*
g) review cpu frequency for all cores/threads:
watch -n 2 'cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq'
h) a couple options to see power draw on battery (as you’ll likely see, they don’t always agree):
sudo powertop -t 10
The first run takes awhile to build up enough data points to show results. Gives an idea of what hardware & processes are using energy. Can also tab through to other views/options. Flag is to update every 10 secs (instead of the default of 20)
or
sudo powerstat -R -c -z 10 1800
Gives W metrics while charging, flags are to start right away and give results every 10 seconds and take 1800 samples (ie: 5 hrs)
or
watch -n 10 'upower -i /org/freedesktop/UPower/devices/battery_BAT1 | grep -e ener -e updat -e perc'
On battery shows the discharge rate updated about every 2 mins, while charging “energy rate” may be the recharge rate?
or via the amdgpu driver stats:
sudo watch -n 10 'head -12 /sys/kernel/debug/dri/0/amdgpu_pm_info'
For the Laptop Zen3/4 SKU’s active is pretty much the only thing you would want. Guided is really for Desktop systems which lack EC with PMU tunings.
Active basically defers to the integrated provided firmware defaults ; which I assume are sanely tuned for setting the performance metrics. Guided basically tells the userspace/kerneland to make adjustment to the perf metrics just based on what kernel/userland is seeing and ignore the firmware/platform hints (if present).
also there are some amd-pstate fixups sitting in patchwork due to a logic error which doesn’t set min/max freq limits which hopefully get pulled into the 6.7 final merge (they didn’t make it into the rc3 merge which closed last night).
That and the pref-cores patches which in theory should move single thread/boost workloads to the most efficent core… possibly will hep with Power.
Thanks @jwp, I appreciate your insights throughout!
My first post on this subject was in another thread and included links to:
AMD Pstate Kernel Doc
TLP Processor & other settings
as that’s where I began in prep for this testing.
Good to know about the pending fixups. I was going to comment on amd-pstate continuing to mature, however decided to present what can be done today from supported OS repos.
I’ve been banging my head against the wall trying to figure out why my limits aren’t being enforced in some situations, thanks for posting this!
This entire thread has been super enlightening and interesting to follow. Changes I’ve made include:
In summary, I’ve gotten a rough improvement of around two hours on total battery life. I have also observed idle wattage drop from around 8-9 to 5-6. All of this with no appreciative drop in performance.
That’s great to hear, glad you’re seeing the desired results as well!
Nothing to add at the moment, tracking this however. Appreciate everyone’s insights!
Thank’s a LOT for these ! Same thing for you guys @jwp @Mario_Limonciello for all the precious technical information here and there, I’ve learnt so much things.
The problem is that those precious comments will get lost in the discussion, and the more the people, the more difficult to read and catch everything. I just wished all those commands (and other commands from this forum that are not only related to power usage) to be centralized in a sticky/readonly mega-thread, without any ‘polluting’ comments for all the novice like me (or … just a technical wiki).
It might be an idea … cc @Matt_Hartley
+1
I’m reasonably competent at dealing with windows problems, but I’m looking to run Ubuntu when I get my FW16, and having read most of the threads here I get lost in all the Linux commands. I assume (yeah, I know about the ass of u in front of me) that these are all being typed into a terminal window, but can’t be sure …
What I would like to see is a sticky thread (or a wiki, I guess) with a list of useful commands (such as ‘uname -r’) which produce information useful for FW support to verify the state of an install, in terms of versions, kernels, and any other relevant bits about its state.
So a go to that people can be pointed at, with probably a table of commands, so when someone posts about a problem they have, they can be directed to a link, and told to furnish the “information of commands 2, 6 and 8” as a first hit at helping diagnose the problem.
A seperate part of the same wiki sounds like it needs a section on installing BIOS updates and FW drivers (I’ve been getting quite confused with fwupdate commands people are told to use, and do they have the right version, or doesn’t it matter?).
I have a laptop with Ubuntu 22.04 LTS on it, and tried the ‘uname -r’ on it, and it came up with a stick of numbers that looked like a kernel revision, but despite it being regularly updated, it doesn’t indicate if it is OEM C or whatever the requirement is. I was looking to put Ubuntu 22.04 on my FW16, but I’m guessing that by the time I receive mine, Ubuntu 24.xx LTS will be available, so this may be a moot point. But some explanation in the wiki of what information the commands provide would also be useful.
I haven’t run Ubuntu since ~the 14.xx series; Mainly for one reason alone.
Ubuntu has what I would call ‘ubuntu-isms’ packages and especially the kernel have distro-specifics things added to them that make them deviate from mainline too much that you end up having to support ‘Ubuntu’ just like you have to support ‘Windows’ vs having to support ‘Linux’ which Fedora, Arch, Debian and all the other distros are much better at doing.
If you are comming from a 0 Starting point; stick to fedora would be my advice. There are certianly some ‘distro-isms’ but specifically around policy for accepting patches ; Fedora basically refuse to ship anything that isn’t already in mainline - this is a tried and tested approach. Ubuntu ends up with delta’s and problems specifics to those deltas that often are fixed in upstream/mainline.
I find it much easier to support people not on Ubuntu; and if you’re going to have a learning curve - you want to try and stick to figuring out the transferable knowledge rather than distro/domain specifics bits.
OK, thanks for the pointer. Appreciated, i’ll try it as a starter on my old laptop in place of the Ubuntu.
My thinking is as we as a community collect more data to create a sticky or how to detailing options, including:
This could be something like PPD + powertop --auto-tune or TLP with the settings detailed like they are currently for the intel version.
The beauty of modern linux distros is you can hit the terminal as little or as much as you desire. (macOS is similar)
The commands I shared are to check what’s happening behind the scenes but they are unnecessary, even to run your own tests!
This is where it is helpful to read the manual (page), such as:
man uname
I encourage trying live versions of the distros you’re interested in and especially trying different window managers (Gnome, Cinnamon, KDE, XFCE, etc).
You can also install to a performant usb drive to see what it’s like to live with for awhile.
I’ve found this series of drives to be great for such a purpose or for rapid backups.
Yeah, I have some similar 128GB ones, I think one is empty at the moment, so will give it a go.
@linuxlion, thanks for the summary above, it was very helpful for me. Especially the systemd patch.
I have one remaining power-hog though. Has anyone else noticed the camera, despite being unused draws 1W+? Any thoughts on a fix?
From powertop:
Blockquote
1.11 W 100.0% Device USB device: Laptop Camera
Sometimes I can reboot and get this to go away, I suspect some app might be triggering it, though closing apps doesn’t fix it once it starts.
UPDATE:
Just after I posted this, I found a work around; If you physically toggle the camera switch to off, power usage goes to zero. I think this is a fine work around, but I’m still curious why it’s not suspending like other devices, when not in use.
I logged in to make that suggestion 
You can look for the camera device via: lsusb
For instance, on mine it shows as:
ID 0bda:5634 Realtek Semiconductor Corp. Laptop Camera
or in the /sys/bus/usb/devices folder and make sure it is flagged to autosuspend.
Knowing the Product ID from above, I found the camera via:
grep 5634 /sys/bus/usb/devices/?-?/id*
or without knowing the id, this also works:
grep -i camera /sys/bus/usb/devices/?-?/product
This indicated mine is in:
/sys/bus/usb/devices/3-1/
So then check auto suspend status (should return ‘auto’):
cat /sys/bus/usb/devices/3-1/power/control
I still take powertop usage details with a grain of salt as they are more of an approximation in my exp.
Enjoy!
Additional Observations
I’ve been running both via TLP and PPD this week and have noted the following.
systemctl status tlp and dmesg for clues, the cause is still inconclusive. There is an updated kernel (6.5.0-1008-oem), so I’ll test that.Thank you for keeping an eye on this. Is FW willing to share its behind the scenes BIOS settings for power management?
This may help inform how to tweak and test things, such as via AMD’s guided pstate.
My primary goal: create a straightforward how-to.
My ultimate goal: longer battery run times on Linux than Win11.
Much appreciated!