Fedora burns twice as much power as Ubuntu

I’m a Linux noob, and I just bought a Thinkpad X1 2-in-1 with Lunar Lake 258v and OLED. I’m running Fedora 43 KDE, and while battery life has been decent (burning around 10% per hour), I’m reading it could be a lot better. Other people with similar-spec laptops (OLED screen included) are reporting around 15 hours of battery life on various Linux distros, and they post idle wattage around 1-2w with screen on, 0.5-1w with screen off.

Mine idles at double that: 4-5W screen on, 2-3W with screen off. I’m consistently running 2-3W above what a lot of others are reporting for similar hardware, even with all my background apps closed and system monitor showing pretty much nothing running.

Using the Power Save profile doesn’t improve battery life at all, even though the system gets noticeably slower. Makes me suspect a hardware component somewhere taking too much power…?

Numbers have been the same whether using kernel 6.17.10, 6.17.12, or 6.18.3.

UBUNTU TEST:

I tested booting Ubuntu 25.10 (kernel 6.17.0) from live USB, and that idles around 2.2W with screen on, even with the main internal SSD mounted.

Screen brightness is 10% in all cases. In KDE I’m using the adaptive refresh rate, and unless Ubuntu turns that on by default, it was off during the Ubuntu tests.

Attached are some screenshots from powertop. As you can see, 4.66w idle isn’t great, especially since Ubuntu idles at less than half that. Anything revealing in these images? I don’t know what I’m looking at…

I previously ran Fedora on an ancient MacBook Air, and adding acpi_osi=”!darwin” to my boot parameters improved the battery life substantially on that machine. Do I need to do something similar here?

Would love any assistance helping me iron this out. I firmly believe this machine isn’t reaching its full potential. Especially when Windows users are getting over 25 hours of battery with it and I can barely squeak 10.

1 Like

The Intel Lunar Lake 258v SoC is a hybrid CPU with a mix of P-cores (performance) and E-cores (efficient), so for various reasons a Linux to Windows – 10 vs. 25 hours – isn’t an apples-to-apples comparison (but it’s inching closer):

Sure, but other Linux users with the same chip and OLED screen are reporting half the idle power draw as my machine.

And Ubuntu is also half the power draw.

1 Like

I wonder if CPU efficiency matters much if all GUI is rendering on GPU likely with Vulkan?

I’m not sure how Windows/DWM handles that differently, but GNOME and GTK stuff defaults to GSK_RENDERER=vulkan (so stuff like Text Editor and Terminals also get GPU accelerated; GPUs are more power-hungry)

some thoughts to help:

  • lastest BIOS or some powersetting in it ?
  • try GPU driver xe instead of i915 ?
  • power save parameter for your Wifi card (modinfo <BE201-module>) ?
  • dark desktop theme and backgrounds
  • try to configure powertop setting:
  1. for all marked “bad”: hit Enter to toggle
  2. take a look in powertops “Wakeup”-Tab too

===

all above powertop settings are gone after an reboot.

so I do it via rc.local:

a) after an clean boot (without an rc.local) run sudo powertop -r mysettings.html

b) open mysettings.html with firefox

c) copy all entries under column “Script” line by line to the following rc.local

better for knowing what is what for:

copy the entries under column “Description” too but place a comment sign “#” in front of it (see example)

d) with an text editor create a file called rc.local with following skeleton:

#!/bin/bash
touch /var/lock/subsys/local

< your output from powertop goes here >

exit 0;

e) copy the powertop output between line beginning with “touch” and “exit”

f) sudo chown root.root rc.local

g) sudo chmod 755 rc.local

h) sudo mv rc.local /etc/rc.d/

i) reboot

j) check if rc.local was loaded via systemctl |grep rc.local

or systemctl status rc-local.service

or the run of powertop

====

following an example rc.local with only some/incomplete entries:

#!/bin/bash
touch /var/lock/subsys/local

# <my-username> to find where I've edited, e.g. via fgrep -r my-username /etc/
# created: 2026-01-08

# NMI watchdog should be turned off
echo '0' > '/proc/sys/kernel/nmi_watchdog';

# VM writeback timeout
echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs';

# Autosuspend for USB device AURA LED Controller [AsusTek Computer Inc.]
echo 'auto' > '/sys/bus/usb/devices/1-2/power/control';

######  Autosuspend for USB device USB Receiver [Logitech]
echo 'auto' > '/sys/bus/usb/devices/1-10.1/power/control';


exit 0;

you need to find out if all settings powertop suggests fits your need !

e.g. here the last entry (Logitech, my mouse) is “auto” and NOT “enabled” what might cause delays using it …

-BIOS is current and set to the most efficient mode (“Balanced”) when on battery (not to be confused with KDE’s power profile, which I keep on Power Saver when on battery)

-GPU is using xe driver

-Not sure how to check/configure power save param for Wifi, pasting that command in parenthesis just gave me an error

-Dark mode for life

-You talking the powertop auto-tuning service? I just got a suggestion from fedoraforum.org to run $ sudo systemctl --now enable powertop, and after doing so, systemctl status powertop shows service: enabled and all the tunables that were Bad are now Good. And it persists across reboots.

I also changed KDE’s Adaptive Sync display setting from “Always” to “Automatic” and after some testing the “Automatic” setting seems to yield a 0.5w decrease in power draw.

After all that, my idle power draw dropped as low as 2.7w with screen on, and KDE’s estimated time remaining, which usually showed about 1 hour per 10% of capacity, now reads 3 hours higher than it used to.

Power usage while browsing around and typing, which used to be 5-7w, is now 3-4w.

So I still have to test it over a full work day and see how it does. But initial results are promising. As I’m typing this the estimated time remaining is 9:26 from 66% charge. Substantial improvement.

Thanks for all the input so far, and of course, further suggestions are welcome!

1 Like

I don’t know how your wifi kernel driver is named.

for an AX201 it is called iwlwifi, so

modinfo iwlwifi

shows at least one power parameter

parm: power_save:enable WiFi power management (default: disable) (bool)

lspci -vnn

will show your wifi driver

here

00:14.3 Network controller [0280]: Intel Corporation Tiger Lake PCH CNVi WiFi 
...
	Subsystem: Intel Corporation Wi-Fi 6 AX201 160MHz [8086:0074]
	...
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

boot parameter might look like (I guess)

iwlwifi.power_save=1 or true

wasn’t aware of this.

1 Like

Ok so mine is also iwlwifi, and it does return:
parm: power_save:enable WiFi power management (default: disable) (bool)

So the boot parameter (iwlwifi.power_save=1 or true) does that go in the grub config? Or somewhere else?

Manjaro forum suggests /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf but I suspect Fedora is different.

UPDATE TO ADD: My average CPU temp has also come down from 39-40C to around 32C while casually browsing.

1 Like

This is an interesting finding, and powertop is a great tool.

I personally do not care much about power efficiency and use performance profile 100%, but curious to see where the discrepancy is coming from.

here are some suggestions, give it a try (i kept links just in case you’ll want to dig deeper):

Analysis of Power Consumption Issue on Fedora 43 KDE

You’ve encountered a known problem: Fedora KDE consumes approximately twice as much power at idle compared to Ubuntu on the same hardware. This isn’t specifically a Lunar Lake issue, but rather a matter of Fedora/KDE configuration and lack of default optimizations.discussion.fedoraproject

Why This Happens

Main causes of high power consumption:

  1. PowerTOP not enabled by default — power-saving settings aren’t activated automatically on Fedora. Ubuntu automatically applies optimizations.fedoramagazine
  2. CPU frequency scaling — On Intel Lunar Lake, intel_pstate with HWP (Hardware-managed P-States) is used, but settings may be suboptimal.wiki.archlinux
  3. ASPM (Active State Power Management) — PCIe bus power management may be disabled, adding 1-2W of consumption.frame+1​
  4. Lack of TLP or tuned — Fedora doesn’t have aggressive power-saving settings by default, unlike Ubuntu.reddit
  5. Background services — KDE and Fedora may have more active background processes consuming resources.discussion.fedoraproject+1​

How to Check Where Energy Is Going

1. Install powertop and run diagnostics:

bash

sudo dnf install powertop
sudo powertop --calibrate  # ~1 hour calibration

After calibration, run in interactive mode:

bash

sudo powertop

What to check:

  • “Frequency stats” tab — CPU should be in high C-states (C8 is deepest)
  • “Idle stats” tab — time spent idle
  • “Tunables” tab — power-saving settings (red = Bad, green = Good)linuxconfig+1​

2. Check CPU frequency scaling driver:

bash

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

On Lunar Lake, it should show intel_pstate. If it shows intel_cpufreq, that’s passive mode.

3. Check ASPM status:

bash

journalctl -b | grep ASPM

It should be enabled. If disabled, add to kernel parameters: pcie_aspm=powersave

4. Review powertop output:

Look at the “Tunables” section for any “Bad” items that can be optimized.redhat+1​

Step-by-Step Optimization

Step 1: Basic optimization with powertop

bash

sudo powertop --auto-tune
sudo systemctl enable powertop.service
sudo systemctl start powertop.service

This activates all “Good” settings. Expect 1-2W reduction.fedoramagazine

Step 2: Use TLP (more flexible option)

bash

sudo dnf install tlp
sudo systemctl enable tlp.service
sudo systemctl start tlp.service

Edit /etc/tlp.conf:

bash

PCIE_ASPM_ON_BAT=powersupersave
CPU_SCALING_GOVERNOR_ON_BAT=powersave
WIFI_PWR_ON_BAT=on
USB_AUTOSUSPEND=1

This should provide 1-2W savings.reddit+1​

Step 3: Enable ASPM in grub

Edit /etc/default/grub:

bash

GRUB_CMDLINE_LINUX="pcie_aspm=powersave"

Then:

bash

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot

Step 4: Use Battery profile in KDE

In KDE power settings, select the “Power Save” profile when on battery. This limits turbo boost and reduces background activity.discussion.fedoraproject

Step 5: Optimize with tuned

Fedora includes tuned for power profiles:

bash

sudo dnf install tuned
sudo systemctl enable tuned
sudo tuned-adm profile powersave

This works well with powertop for comprehensive optimization.discussion.fedoraproject

Lunar Lake Specific Considerations

Several Fedora users on Lunar Lake have achieved 3-4W during light usage using the balanced-battery profile with powertop. On ThinkPad X1 Carbon with 258v, some reached 12+ hours battery life with a 56Wh battery.reddit

Critical note: Lunar Lake only supports s2idle (not S3 deep sleep), which means minor drain during suspend (~1.3%/hour) is normal.discussion.fedoraproject+1​

Verifying Results

After all optimizations, run:

bash

sudo powertop --calibrate
sudo powertop  # after an hour of data collection

Target result: 2.0-2.5W at idle with screen at 10% brightness, Wi-Fi enabled.

About acpi_osi=“!darwin”

This parameter was needed for old MacBooks. On modern Lunar Lake, it’s not required and may cause issues — don’t add it unless necessary. Lunar Lake initializes correctly with default ACPI settings.kernel+1​

Final Recommendation

Start with powertop --auto-tune, then install TLP with ASPM powersupersave, and verify results through powertop. If there’s still a difference under 1W, it may simply be distribution-level differences in background services. In that case, optimize background processes (disable unnecessary systemd services, ensure Bluetooth and Wi-Fi aren’t constantly active in the background).discussion.fedoraproject+3​

Assisted-by: Perplexity

create a file called iwlwifi_powersave.conf under /etc/modprobe.d/

content:

options iwlwifi.power_save=1

reboot

OR

see above regarding Step 3:

add (!!!) iwlwifi.power_save=1 to the GRUB_CMDLINE_LINUX

so it reads

GRUB_CMDLINE_LINUX=” iwlwifi.power_save=1 rhgb quiet”

run sudo grub2-mkconfig -o /boot/grub2/grub.cfg and sudo reboot

Point of information…
in the Ubuntu install you compared against using Wayland or Xwindows mode for your desktop?

I ask because when I installed powertop just now on my system in requires xset.. which is an Xwindows utility… so that got me thinking that the Wayland versus Xwindows is probably the largest possible difference in terms of architecture codepaths that could be showing up in a differential analysis approach.

What you call idle draw..isn’t actually idlle…right.. there’s stuff going on that you’re not going to be able to see in the snapshots that system-monitor provides. In fact running the graphical system-monitor application itself may actually may make the idle draw look worse.. if the difference in performance really is Wayland versus XWindows related behavior.
if your looking at a window and it doing any visual refreshing.. the system isn’t..idle…and there might be just enough CPU activity to keep the CPUs from dropping their operating frequency down into the lowest power consumption state.

So the very first thing I’d do in conducting a differential analysis of idle power draw is to keep a track of the cpufrequencies. Since the CPU scaling governors are ‘smart’ you’ll need to take snapshots of this and average. You can watch the scaling semi-live with

watch -n1 "grep \"^[c]pu MHz\" /proc/cpuinfo"

that’s 1 second live updates. If you don’t see all the cores bottom out and stay bottomed out while you are watching.. the system isn’t actually idle and you arent getting an good representation of idle.
But Jef.. running that watch command keeps a CPU active..
Yep!
Then you have to get into pinning your diagnostic software to a specific CPU and then making sure your analysis ignores the CPU your using to run the diagnostic tools. Everything you do to try to see idle state power draw takes a at least 1 CPU, of the system out of idle state. Do what you can to pin your diagnostic tools to a CPU you plan to ignore in your analysis.

Oh and for differential analysis reasons you’ll want to confirm that the lowest available frequency is the same on all configurations under test.. lscpu command should be a reliable way to quickly surface the tunable min/max settings. You might want to use lscpu -a -e to ensure you see what the per CPU min/max settings are. Tunables are FUN!..in the dentist visit sense.

Anyways… the easiest way to isolate the impact of the windowing system broadly is to drop down to a non-graphical runtime where the graphical system isn’t running at all and rerun your differential analysis on power consumption and see if getting out of graphical UI brings the idle draws across systems closer to a common baseline. (traditionally that’s runlevel 3)… in systemd era that means switching to the multi-user target from the graphical target. At the very least you’ll learn how to use systemctl isolate command as a means to jump back and forth between available targets.

You may actually want to go to the rescue target as the most minimal baseline for your differential analysis. This will help ensure you minimize the impact on background services that may be running that are different across systems. The goal here is to start with a differential analysis with as minimal number of running processes as possible so you can make a reasonable determination if this is something in the kernel or something in userspace. A truly idle cpu baseline means turning off as much background stuff as you can.. rescue mode is a starting point for that. If you can’t get similar enough idle power draws when comparing rescue mode.. that has implications. Regardless you’ll want to double check and confirm that the list of active systemd managed services is similar in a baseline comparison or else you’ll have a dickens of a time intepreting any of your findings.

The next largest differences involve versions of codepaths..

the most obvious is the kernel. This gets complicated because the kernel’s behavior with regard to power management is tunable hence why powertop output all the “Runtime PM” stuff marked bad are kernel tunables. So even when comparing exact same version numbers of the kernel.. you have to ask questions like… are there out of tree patches being applied that would impact this (not as likely when comparing system using kernels close to upstream latest release..but possible), its more likely there are differences in the runtime tunable parameters…but to really understand whats at play here you have to do a differential analysis of the tunable settings for the devices.. which means getting familiar with sysconfig and the sysfs virtual filesystem mounted at /sys

The kernel tunable stuff gets complicated… because there are SO MANY TUNABLES and you can get lost in the weeds a bit. Though I’m suspicious there’s a difference in the CPU scaling governors (if this doesn’t come down to the graphical desktop architecture differences having an impact on how the governor chooses when its okay to drop the CPU frequency down to its lowest available level)

The next possible difference in versioned shared components is systemd.. but I think that’s comes down to mostly systemd doing runtime configuration of some tunables.. so its a similar differential analysis to just understanding wtf the actually runtime tunables are for your system.

The next largest difference is things like versions of the frameworks in use on your desktop.
If your running KDE on both, are they the same versions using the same versions of Qt? Much less likely an impact than the architectural differences of Wayland versus Xwindows..but its possible there are versioned differences in behavior going on.

Then after that we get into dbus based background services that the desktops are running sort of behind the scenes. system-monitor snapshots wouldn’t necessarily capture all the dbus traffic impact on CPU frequency scaling. But if you drop down into the console only target as a broad test of the impact of desktop you’ll at least be able to know if its a factor you need to dive into. Again this is sort of a background chatter issue that would prevent the CPU governor algorthims and related device firmware from thinking the system is idle enough to drop to a lower operating frequency. Because at the end of the day CPU idle power consumption is really just a measure of what frequency they are running… and the automatic scaling stuff tries to be “smart” and do a trade off here and only lets CPUs drop down when the system is “idle enough”… the behind the scenes desktop operational chatter can impact what the CPUs see in a way that you as a user don’t. Watch the dbus message logs on an otherwise idle system with system monitor GUI open versus running top in a terminal.

Good luck and good hunting.
Depending on what you find in a more comprehensive differential analysis.. there might be something actionable.. there might not be. I’m suspicious there is an inherent performance penalty associated with Wayland which probably isn’t news to anyone who is working on it.

1 Like

Thanks a ton for all of this. Getting powertop’s auto-tune service running yesterday already made a substantial difference saving 1-2w across the board as expected and all tunables report “good” now.

Frequency scaling driver is using intel_pstate, so all good there.

On the ASPM topic, I ran the check on ASPM status and got this:

Jan 08 10:30:02 Dawnpoint-II kernel: acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
Jan 08 10:30:02 Dawnpoint-II kernel: pci 0000:00:1c.4: ASPM: current common clock configuration is inconsistent, reconfiguring

I’m not sure what that means, but it doesn’t seem to be all that “enabled…” Should I proceed with adding the grub launch parameter?

My only hesitation is using TLP, and here’s why: thermals on this laptop aren’t great, and if I use KDE’s “Performance” mode for gaming, it runs amazing, then gets hot and throttles and runs crappy, then cools and runs amazing, then throttles, on and on for an endless loop. If I keep it in Balanced mode, I actually get much better game performance, no throttling, and consistently lower temps. So for now I’d like to keep this part of the setup as-is, since it’s performing how I like. It does automatically switch to Power Save when on battery.

1 Like

Thanks for all of the great suggestions in this thread!

One question: How to install Powertop and tlp in an Atomic distro? I’m on F42 Kinoite. Layering? Or will they work from a Toolbox?

Thanks!

1 Like

@andym Your post has been hidden until it is adjusted to comply to the AI policy. Please review the AI policy at Making sure you're not a bot! , adjust the content correspondingly, and then it will become visible again. Thanks :classic_smiley:

1 Like

Besides the AI Policy issue, I find it quite rude, frankly, to dump this much AI text into a conversation. If somebody wants an answer from an LLM, they can ask their favorite one themselves. If somebody asks in here, my assumption is that this is intentional to get a response from a real person who actually knows what they are doing.

3 Likes

Unfortunately, many people don’t know how to do good prompts and/or do not have access to quality models that actually give you excellent advice.

If the model response is helpful (which it is, and in many cases way better and more detailed than most posts in some threads) and helps - why not?

rude or not it’s opinionated. In the modern world we have to adapt to the new tools.

i have added an AI remark to the post as the policy asks.

1 Like

Have you verified all 128 lines and 585 words that you pasted and are you prepared to vouch for its correctness and effectiveness?

That’s why I prefaced it with “I find it …”.

Sure, I use LLMs where it makes sense. And nobody is taking your choice to use them away. But if you dump several screen pages of it into a thread, you are forcing your choice to use them on all other participants in the thread. That is what I find rude.

3 Likes

Absolutely. With some practice you quickly see whether the response is helpful or not. I use a lot of various AI tools and found ways to tackle very technical issues quickly and efficiently, which enabled me to migrate to Linux from Windows permanently.

in case anything is incorrect (as happens with human-generated content too), other users will spot it and comment, right?

1 Like

So I added pcie_aspm=powersave and iwlwifi.power_save=1 to my GRUB_CMDLINE_LINUX= in etc/default/grub, but neither resulted in any change.

The ASPM check still returns

Jan 08 10:30:02 Dawnpoint-II kernel: acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
Jan 08 10:30:02 Dawnpoint-II kernel: pci 0000:00:1c.4: ASPM: current common clock configuration is inconsistent, reconfiguring

And the modinfo iwlwifi check still returns

parm: power_save:enable WiFi power management (default: disable) (bool)

1 Like

I found this link, which answers my question: [PSA] powertop + tuned = better power profiles

1 Like