A Look At The Windows 10 vs. Linux Power Consumption On A Dell XPS 13 Laptop

[Degra]

I cannot believe Fedora is not only competitive with GNOME, but is scoring best. Whatever they changed under the hood, it's working wonders.
In most DE benchmarks, GNOME usually scores worst in terms of power efficiency.
I would really like to see Fedora's changes get applied in more lenient distros running LXDE/XFCE/Cinnamon and see what the power effiency is like.

[LinuxID10T]

I think someone mentioned it already but would love to see some results with PowerTOP being used.

[mlau]

On Intel CPUs, please don't forget to use "x86_energy_perf_policy --all power" to make the CPU an extra bit less power hungry. Linux kernel by default sets this to the equivalent of "normal", while Clear Linux kernel AFAIK sets it to "performance" (the bios default, incidentally).

[M@yeulC]

I am concerned that this might not be representative of battery results, though :/

[heliosh]

From the diagram it looks like the measurement sampling rate is too low to make a meaningful comparison

[andre30correia]

with tlp the things become a lot lower even with default settings, using powertop the things are even better, disable intel pstate even better

[Michael]

I think someone mentioned it already but would love to see some results with PowerTOP being used.

Yes that will be in a separate article, this is just about stock performance.

[Hi-Angel]

Interesting. To be honest I expected Win10 to perform worse.

[Venemo]

Michael, on my skylake notebook I got some more power savings by enabling the following kernel options (added to the kernel boot parameters):

pcie_aspm=force
i915.i915_enable_rc6=1	(needed to disable VT-d for it to work)
i915.i915_enable_fbc=1	(can cause graphical glitches)
i915.i915_ldvs_downclock=1
drm.vblankoffdelay=1	(not sure if this was for a workaround?)

Also changing SATA power management options helped a lot, but I think that notebook has NVMe, so anything I did is probably not applicable.

I know a lot of people like to advertise these i915 kernel options, but please do NOT blindly suggest them to everyone. Some of them are no longer present on newer kernels (such as enable_rc6 and lvds_downclock). Some of them are now enabled by default (such as enable_fbc), and some cause instability (such as fastboot and enable_psr).

The vblankoffdelay setting is documented here: https://01.org/linuxgraphics/gfx-doc...cal-blank.html - considering what it does I'm not actually sure if it makes sense to set it to 1 (unless required by buggy hardware), and it doesn't cause a measurable improvement in power consumption. With regards to pcie_aspm=force that should only be used on systems that do support aspm but have some sort of buggy firmware (which reports that it isn't supported when in fact it is). Otherwise it will cause instability (if used on a system which does not support ASPM).

Bottom line:
The options that did have an impact on power consumption were enable_rc6 which is no longer there but I suspect the driver can figure it out on its own now, and enable_fbc which is by default enabled on this laptop. And I would recommend against using the others unless you have buggy hardware that needs them.

[grigi]

Some more options tested for my Skylake XPS 13 with glossy display on 4.16: i915.enable_psr=2 (1 causes glitches) and i915.fastboot=1

Loading GUC firmware works fine as well (i915.enable_guc_loading=1, i915.enable_guc_submission=1).

I also found out that disabling the built-in SD card reader in the BIOS makes a measurable difference in power draw, which probably indicates a failure in PCIe power saving features for that particular Realtek part.

Ok, so I read up on it a bit. turns out i915.enable_rc6=1 is not needed since 4.16, and for GuC/HuC you need to instead specify i915.enable_guc=-1
Also fastboot is the default since 4.4 so also not needed.

So my /etc/default/grub kernel parameters changed to:
pcie_aspm=force
i915.i915_enable_fbc=1
i915.i915_ldvs_downclock=1
i915.enable_psr=2
i915.enable_guc=-1
acpi_backlight=vendor
drm.vblankoffdelay=1

Now both HuC and GuC loaded, and the performance of Talos also went up by about 5% (could be margin of error)
But the nice thing is the artefacts caused by frame-buffer-compression seemingly disappeared after loading HuC/GuC firmwares.

I'll keep an eye on anything, and report back.