Increased power consumption after switch from Mint to Manjaro

Support
,
1

Hi,

I have been using Linux Mint with Cinnamon for many years but decided to give Manjaro Linux with Gnome a try. Therefore I am new in this forum. The general setup has worked well but I am noticing significantly increased power consumption on Manjaro compared to Mint 20.3.

I have an Asus UX325 with i7-1165G7. In Mint the idle power consumption is ~4-4.5W. In Manjaro it is 6.5-8.5W. To exclude that it is due to the desktop environment (Gnome vs. Cinnamon), I have also installed Cinnamon on Manjaro but this shows a similarly increased power consumption.

I am using TLP with the same parameters configured in Mint and Manjaro. Powertop shows that the package C-states in Manjaro do not reach levels below C2 (pc2) even though the individual cores reach the deepest C7 stages for >>90%. The GPU reaches RC6. In Mint the individual cores reach the same levels but the package C-states go way below and reach C8 (pc8). I suspect that the failure to reach deep package C-states is the reason for the increased power consumption in Manjaro.

Unfortunately, I have not found a way to make the CPU reach deeper package C-states on Manjaro. I have compared the output of tlp-stat in Manjaro and Mint but do not see a difference. Kernel in Mint 20.3 is the HWE kernel (5.13 Ubuntu). Kernel in Manjaro is 5.15. I also tried 5.10 and 5.17 with the same result. I noted that Manjaro uses a newer microcode for the CPU but doubt that this is relevant.

I would greatly appreciate any suggestions on what may be incorrectly configured. Is it possible that the Mint/Ubuntu kernel has some optimisations that Manjaro is missing?

Please let me know if I should provide the output of any commands. I wanted to attach the output of tlp-stat on Manjaro and Mint but did not see a way to attach files.

Many thanks and best wishes

Karl

1 Like
2

This could be perfectly relevant since the microcode also patches c-state behavior. Worth a try would be removing it and booting without it.

3

Many thanks for the suggestion! I blocked loading of the microcode update but, unfortunately, no change in power consumption and C-state behavior.

4

The difference could be also, the driver and the governor.

What is used on your system?

inxi -Cazy
5

Please find the output in Manjaro and Mint below,. Many thanks for the help!

Manjaro:

CPU:
  Info: model: 11th Gen Intel Core i7-1165G7 bits: 64 type: MT MCP
    arch: Tiger Lake family: 6 model-id: 0x8C (140) stepping: 1 microcode: 0xA4
  Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
    L1: 320 KiB desc: d-4x48 KiB; i-4x32 KiB L2: 5 MiB desc: 4x1.2 MiB
    L3: 12 MiB desc: 1x12 MiB
  Speed (MHz): avg: 1268 high: 1301 min/max: 400/4700 scaling:
    driver: intel_pstate governor: powersave cores: 1: 1300 2: 1301 3: 1242
    4: 1219 5: 1203 6: 1281 7: 1300 8: 1301 bogomips: 44864
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 status: Vulnerable: eIBRS with unprivileged eBPF
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected

Mint (without the y parameter as this resulted in an error message):

CPU:
  Topology: Quad Core model: 11th Gen Intel Core i7-1165G7 bits: 64 
  type: MT MCP arch: Tiger Lake family: 6 model-id: 8C (140) stepping: 1 
  microcode: 88 L2 cache: 12.0 MiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 44851 
  Speed: 1352 MHz min/max: 400/4700 MHz Core speeds (MHz): 1: 1301 2: 1301 
  3: 1301 4: 1300 5: 1300 6: 1300 7: 1300 8: 1301 
  Vulnerabilities: Type: itlb_multihit status: Not affected 
  Type: l1tf status: Not affected 
  Type: mds status: Not affected 
  Type: meltdown status: Not affected 
  Type: spec_store_bypass 
  mitigation: Speculative Store Bypass disabled via prctl and seccomp 
  Type: spectre_v1 
  mitigation: usercopy/swapgs barriers and __user pointer sanitization 
  Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB filling 
  Type: srbds status: Not affected 
  Type: tsx_async_abort status: Not affected

Even though the inxi command does not show it on Mint, it uses the same driver and governor. This is an excerpt of the tcp-stat output in Mint:

/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver    = intel_pstate
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor  = powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors = performance powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq  =   400000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq  =  4700000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference = balance_power
6

my personal experience with the intel_pstate-governor is a disapointment. the idea is well, the practice of it is poorish. after switching back to the “original” governor-control the efficiency is far way better.
to do so edit /etc/default/grub and add “intel_pstate=disable” to the existing entries of GRUB_CMDLINE_LINUX_DEFAULT. you need sudo-rights to edit the file.
after editing

sudo update-grub
sudo mkinitcpio -P

and reboot.

7

If Mint works better there’s no apparent reason to use Manjaro :slight_smile:

You will have to tweak your powersettings

I have a Lenovo T550 - 2 batteries - last for 18 hours … running a trimmed down KDE/Plasma

8

Many thanks! I have tried this parameter already. It then uses a different governor but did not make a difference regarding power consumption and c states.

9

well, you could dig deeper how the acpi-settings are. they will affect the control of the power-management.

10

I really liked the rolling release idea…

I have played around with all options available in tlp but could not get it into deeper package c states. I am getting more and more convinced that there may be something special in the Ubuntu kernel. I wonder if there is a way to install the Ubuntu kernel in Manjaro just to try it out.

1 Like
11

no, the kernel are always the same. it’s just the setup and you can’t rely that these settings are preconfigured in the right manner if you run an rolling-release. in this case stable releases do a better job indeed.

12

I don’t think so.

It is a matter of configuration - perhaps Linux Mint sets up some predefined power settings - that could be - what I would do if I needed so - search a default Mint install for the power settings.

13

Many thanks for the suggestions. I tried the suggested kernel parameters but no improvement.
I have tried to look carefully into all power management options but could not find any with a different setting than in Mint. As I can boot into both environments and compare, I could compare the settings. It is of course possible that there is an option that is not exposed in tlp and I do not know about.

Does anyone know about a documentation that lists ALL available power-relevant settings?
The other possibility is some background task in Manjaro that keeps the CPU busy and prevents deeper package C states. However, I noticed the increased power consumption even if Gnome is not active, i.e. when switching from the login screen to a terminal and running powertop. So, it would have to be a program that is independent of the Gnome environment. If anybody has a suggestion how to troubleshoot this, that would be great.

14

https://wiki.archlinux.org/title/Power_management

15

@KMK Since Gnome is used, there are 2 power management service which are in conflict.

sudo systemctl status upower.service
sudo systemctl status tlp.service
16

Many thanks! I went through all of this but the tlp-stat output shows that this should be all taken care of.

I stopped the upower service but no change in power consumption.

17

I think I have proven that it is the kernel itself!

I copied the Mint kernel, initramfs and modules from the Mint installation into Manjaro and manually edited the boot info in grub to point to these files. Then I verified in Manjaro that the Mint kernel was loaded:

uname -a                                                         ✔ 
Linux UX325 5.13.0-44-generic #49~20.04.1-Ubuntu SMP Wed May 18 18:44:28 UTC 2022 x86_64 GNU/Linux

Now powertop is back to ~4W power consumption and the package reaches C8 (pc8) C state. No other settings were changed.

I think this definitely proves that something is wrong with the Manjaro kernel. If it is a different default to Mint/Ubuntu, it could be fixed with a kernel parameter at boot. If it is some patch, however, I will have to return to Ubuntu/Mint. I am not sure if there is a way to figure this out…

1 Like
18

hm… Manjaro retrieves the kernel directly from the original repo and do only small customization.

Therefore: There is something wrong with the original source. Look here: PKGBUILD · master · Packages / Core / linux515 · GitLab

Also, Ubuntu is sticking to an EOL kernel here, which they manually patch themselves. So probably only bugfixes and security patches.

You tried different kernels in Manjaro right? All of them have the same issue?

$ mhwd-kernel -l 
available kernels:
   * linux419
   * linux510
   * linux515
   * linux517
   * linux518
   * linux519
   * linux54
   * linux515-rt
   * linux518-rt
19

Yes, I tried all non-realtime kernels that are available in the Manjaro Settings Manager: 5.10.117-1, 5.15.41-1, 5.17.9-1 and 5.18rc7 with the same result.

I did notice that there are some differences in the kernel .config file used for the build between Mint and Manjaro and some of these options relate to the CPU. For example:

> CONFIG_PROCESSOR_SELECT=y
410,415c399,404
< # CONFIG_GART_IOMMU is not set
< # CONFIG_MAXSMP is not set
< CONFIG_NR_CPUS_RANGE_BEGIN=2
< CONFIG_NR_CPUS_RANGE_END=512
< CONFIG_NR_CPUS_DEFAULT=64
< CONFIG_NR_CPUS=320
---
> CONFIG_GART_IOMMU=y
> CONFIG_MAXSMP=y
> CONFIG_NR_CPUS_RANGE_BEGIN=8192
> CONFIG_NR_CPUS_RANGE_END=8192
> CONFIG_NR_CPUS_DEFAULT=8192
> CONFIG_NR_CPUS=8192
423c412
< # CONFIG_X86_MCELOG_LEGACY is not set
---
> CONFIG_X86_MCELOG_LEGACY=y
432c421
< CONFIG_PERF_EVENTS_INTEL_UNCORE=m
---
> CONFIG_PERF_EVENTS_INTEL_UNCORE=y
435,436c424
< CONFIG_PERF_EVENTS_AMD_POWER=m
< CONFIG_PERF_EVENTS_AMD_UNCORE=m
---
> # CONFIG_PERF_EVENTS_AMD_POWER is not set
447,449c435,437
< # CONFIG_MICROCODE_OLD_INTERFACE is not set
< CONFIG_X86_MSR=y
< CONFIG_X86_CPUID=y
---
> CONFIG_MICROCODE_OLD_INTERFACE=y
> CONFIG_X86_MSR=m
> CONFIG_X86_CPUID=m
452c440
< CONFIG_X86_CPA_STATISTICS=y
---
> # CONFIG_X86_CPA_STATISTICS is not set
459c447

OR

> # CONFIG_ACPI_APEI_ERST_DEBUG is not set
617d614
< CONFIG_ACPI_VIOT=y
619d615
< CONFIG_ACPI_PRMT=y
643,644c639,640
< CONFIG_X86_PCC_CPUFREQ=m
< CONFIG_X86_ACPI_CPUFREQ=m
---
> CONFIG_X86_PCC_CPUFREQ=y
> CONFIG_X86_ACPI_CPUFREQ=y
646c642
< CONFIG_X86_POWERNOW_K8=m
---
> CONFIG_X86_POWERNOW_K8=y
648c644
< # CONFIG_X86_SPEEDSTEP_CENTRINO is not set
---
> CONFIG_X86_SPEEDSTEP_CENTRINO=y
677a674,675
> # CONFIG_PCI_CNB20LE_QUIRK is not set
> CONFIG_ISA_BUS=y
679a678
> # CONFIG_X86_SYSFB is not set
686c685
< # CONFIG_X86_X32 is not set
---
> CONFIG_X86_X32=y
692a692,740

If I understand this correctly, there are multiple parameters in Manjaro (lines indicated with <) that build modules (“m”) instead of including in the kernel directly (“y”). Maybe a relevant module is not loaded.

1 Like
20

It’s a bit harder to compare, since you don’t have 5.13 available on Manjaro, ie. maybe something was included in 5.11-5.13 that was reverted in 5.14.

I guess next step is to compile manjaro kernel with mint’s config. If that works, remove 50% of mint’s config, etc.