How to handle cpu interrupts that causes high cpu usage

Hi all!
I have some problems with cpu usage in manjaro…
I noticed a while back that in KSysGuard one of cpu cores is showed to be always at 0% usage, while if I check htop the same core is showed to be at 100% usage, even if there’s no process that is really utilizing all that power.
Before landing on manjaro I in fact tried a number of debian/ubuntu based distros and in all of them one CPU core was always at 100% usage, making the system laggy and unusable, but manjaro works very good on my laptop so I thought that there simply was a bug somewhere that affected CPU monitoring.
This morning though I got curious and looked into it: I found this post regarding Ubuntu and the same issue and the first advice is to check for strange value in interrupts with
grep . -r /sys/firmware/acpi/interrupts/
So I did and in fact there are very strange values on some parameters, take a look:

/sys/firmware/acpi/interrupts/gpe26: 2575560 EN STS enabled unmasked

/sys/firmware/acpi/interrupts/sci: 2575593

/sys/firmware/acpi/interrupts/gpe_all: 2575673

I just extrapolated this three values cause all the others are 0, but I can post the whole output if it helps.
The post on Ubuntu that I linked before offers a solution, but it’s a very old post and a different distro, so should I follow that instructions?
Is there something else I should do or check?

Although my pc is veru usable I noticed very high battery draining even with TLP enabled and configured and I think this is whats causing the problem… any ideas?

Here’s my inxi -Fazy if you need it

  Kernel: 5.4.74-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.0 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.4-x86_64 
  root=UUID=5f7a7ef9-ca3d-413a-8734-f763cb82c6ef rw pci=noaer quiet apparmor=1 
  security=apparmor resume=UUID=bc81d4a7-d397-440e-9225-c2eae38cb1df 
  Desktop: KDE Plasma 5.20.2 tk: Qt 5.15.1 wm: kwin_x11 dm: SDDM 
  Distro: Manjaro Linux 
  Type: Laptop System: ASUSTeK product: X541UAK v: 1.0 serial: <filter> 
  Mobo: ASUSTeK model: X541UAK v: 1.0 serial: <filter> 
  UEFI: American Megatrends v: X541UAK.311 date: 03/14/2018 
  ID-1: BAT0 charge: 26.0 Wh condition: 27.9/34.6 Wh (81%) volts: 10.8/10.8 
  model: ASUSTeK ASUS Battery type: Li-ion serial: N/A status: Charging 
  cycles: 392 
  Info: Dual Core model: Intel Core i3-6006U bits: 64 type: MT MCP 
  arch: Skylake family: 6 model-id: 4E (78) stepping: 3 microcode: D6 
  L2 cache: 3072 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 16006 
  Speed: 2000 MHz min/max: 400/2000 MHz Core speeds (MHz): 1: 2000 2: 2000 
  3: 2000 4: 2000 
  Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
  Type: l1tf 
  mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
  Type: meltdown mitigation: PTI 
  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: Full generic retpoline, IBPB: conditional, 
  IBRS_FW, STIBP: conditional, RSB filling 
  Type: srbds status: Vulnerable: No microcode 
  Type: tsx_async_abort status: Not affected 
  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: ASUSTeK driver: i915 
  v: kernel bus ID: 00:02.0 chip ID: 8086:1916 
  Device-2: IMC Networks USB2.0 VGA UVC WebCam type: USB driver: uvcvideo 
  bus ID: 1-6:3 chip ID: 13d3:5a01 serial: <filter> 
  Display: x11 server: X.Org 1.20.9 compositor: kwin_x11 driver: intel 
  display ID: :0 screens: 1 
  Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.2x8.0") 
  s-diag: 414mm (16.3") 
  Monitor-1: eDP1 res: 1366x768 hz: 60 dpi: 102 size: 340x190mm (13.4x7.5") 
  diag: 389mm (15.3") 
  OpenGL: renderer: Mesa Intel HD Graphics 520 (SKL GT2) v: 4.6 Mesa 20.2.1 
  direct render: Yes 
  Device-1: Intel Sunrise Point-LP HD Audio vendor: ASUSTeK 
  driver: snd_hda_intel v: kernel alternate: snd_soc_skl bus ID: 00:1f.3 
  chip ID: 8086:9d70 
  Sound Server: ALSA v: k5.4.74-1-MANJARO 
  Device-1: Realtek RTL810xE PCI Express Fast Ethernet vendor: ASUSTeK 
  driver: r8169 v: kernel port: e000 bus ID: 02:00.2 chip ID: 10ec:8136 
  IF: enp2s0f2 state: down mac: <filter> 
  Device-2: Realtek RTL8723BE PCIe Wireless Network Adapter vendor: Lite-On 
  driver: rtl8723be v: kernel port: d000 bus ID: 03:00.0 chip ID: 10ec:b723 
  IF: wlp3s0 state: up mac: <filter> 
  Local Storage: total: 577.55 GiB used: 166.27 GiB (28.8%) 
  SMART Message: Unable to run smartctl. Root privileges required. 
  ID-1: /dev/sda vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB 
  block size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s serial: <filter> 
  rev: 023 scheme: GPT 
  ID-2: /dev/sdb vendor: Crucial model: CT120BX500SSD1 size: 111.79 GiB 
  block size: physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> 
  rev: R013 scheme: GPT 
  ID-1: / raw size: 161.13 GiB size: 157.60 GiB (97.81%) 
  used: 59.75 GiB (37.9%) fs: ext4 dev: /dev/sda5 
  Kernel: swappiness: 60 (default) cache pressure: 100 (default) 
  ID-1: swap-1 type: partition size: 3.91 GiB used: 0 KiB (0.0%) priority: -2 
  dev: /dev/sda7 
  System Temperatures: cpu: 45.0 C mobo: N/A 
  Fan Speeds (RPM): cpu: 2300 
  Processes: 181 Uptime: 36m Memory: 7.66 GiB used: 1.46 GiB (19.1%) 
  Init: systemd v: 246 Compilers: gcc: 10.2.0 Packages: pacman: 1470 lib: 469 
  flatpak: 0 Shell: Bash v: 5.0.18 running in: konsole inxi: 3.1.08

I was able to figure it out myself!
I should have searched the internet more carefully before posting…
If anyone has the same problem I followed this Reddit post: it’s as simple as creating a systemd service that starts on boot and disables the specific ACPI interrupts that give you problems.
Now my CPU usage is normal and I think it will improve battery life, it seems to discharge more slowly and now it tells me I have 4/5 hours left instead of 2.
Have a great day!

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.