8

I noticed that, on my ASUS N550JV, my load average was always above 1.

I'm using Devuan Beowulf with a 4.19.0 kernel.

After some digging I found that the culprit was a kworker related to ACPI.

empire# pidstat 10      
Linux 4.19.0-5-amd64 (empire)   30/08/2019      _x86_64_        (8 CPU)

12:34:18      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
12:34:28        0      3108    0,00    0,10    0,00    0,00    0,10     0  irq/38-nvidia
12:34:28      100      3201    0,10    0,00    0,00    0,00    0,10     5  dbus-daemon
12:34:28        0     14563    0,00   67,33    0,00    0,30   67,33     0  kworker/0:2-kacpi_notify
12:34:28        0     18056    0,40    0,60    0,00    0,20    1,00     4  Xorg
12:34:28     1000     18152    0,10    0,00    0,00    0,00    0,10     1  i3bar
12:34:28     1000     19570    0,20    0,00    0,00    0,00    0,20     4  chromium
12:34:28     1000     19618    0,00    0,10    0,00    0,00    0,10     5  chromium
12:34:28     1000     19857    0,10    0,00    0,00    0,00    0,10     3  x-terminal-emul
12:34:28        0     20254    0,00    0,10    0,00    0,00    0,10     5  kworker/5:0-events_freezable
12:34:28     1000     22871    1,70    0,70    0,00    0,10    2,40     2  telegram-deskto
12:34:28        0     23314    0,00    0,10    0,00    0,10    0,10     5  kworker/5:3-pm
12:34:28        0     23899    0,00    0,10    0,00    0,00    0,10     6  pidstat

You see that kworker/0:2-kacpi_notify at 67%?

So I dug into what may cause this, and stumbled upon this question on Unix & Linux SE.

So digging inside /sys I got:

empire# grep . -r /sys/firmware/acpi/interrupts | grep -v "  0"
/sys/firmware/acpi/interrupts/gpe13: 3646789     STS enabled      unmasked
/sys/firmware/acpi/interrupts/sci: 3646793
/sys/firmware/acpi/interrupts/gpe_all: 3646799
/sys/firmware/acpi/interrupts/gpe19:       5  EN     enabled      unmasked

If I echo disable > /sys/firmware/acpi/interrupts/sci and the same for gpe13 the load average drops off to a reasonable number.

My questions are:

  1. is this the best way to fix it? Are there "cleaner" alternatives?
  2. are there any negative side effects?
4
  • 1
    I just realized... should I have posted this in Unix & Linux? If so I can delete and reopen over there
    – miniBill
    Aug 30, 2019 at 10:44
  • I've already got the latest BIOS version
    – miniBill
    Sep 2, 2019 at 20:07
  • Have you found a "cleaner" alternative? Are you still having the problem in newer kernels? Using the individual disable per IRQ, solves it for me, but acpi=noirq on the boot options does not -- I've tried with 4.19.80 and 5.3.11 kernels.
    – Daniel
    Nov 21, 2019 at 0:05
  • I'm currently using my distro's kernel, haven't tried with newer ones. Have found no cleaner solutions sadly
    – miniBill
    Nov 21, 2019 at 7:20

1 Answer 1

-1

The ACPI system uses two types of interrupts (sci and gpe13) to perform various functions on your system. Disabling these interrupts could potentially cause problems with power management, device detection, or other ACPI-related features.

Some negative consequences you might experience if you disable the sci interrupt include:

  • Decreased power management capabilities: The sci interrupt is used by the ACPI system to monitor power-related events, such as pressing the power button or removing the AC adapter.

  • Decreased device detection and configuration: The sci interrupt is also used by the ACPI system to detect and configure devices, such as hard drives, keyboards, and USB devices. Disabling this interrupt could prevent these devices from being detected or configured correctly, causing problems with using them.

  • Decreased system performance: The sci interrupt is used by the ACPI system to perform performance-related tasks, like CPU frequency scaling and thermal management. Disabling this interrupt could impact the system's ability to optimize performance, resulting in slower performance overall.

The negative consequences of disabling the gpe13 interrupt might be similar to those of disabling the sci interrupt, as the ACPI system also uses gpe13 for various functions. It's hard to predict exactly what the impact of disabling gpe13 would be, as it depends on how it is being used on your specific system.

One potential "cleaner" alternative would be to try to identify the root cause of the issue and address it directly. Here are a few things you could try:

  1. Check for any updates or bug fixes related to the kernel or ACPI. It's possible that the issue you're experiencing has already been identified and fixed in a newer version of the kernel or other system component.

  2. Check for any hardware issues. If you've recently added any new hardware to your system or if you've noticed any other hardware-related issues, it's possible that the problem is related to hardware rather than software.

  3. Check for any issues with your power management configuration. Make sure that your power management settings are configured correctly, and consider disabling any power management features that you're not using.

It's also worth noting that a load average above 1 is not necessarily indicative of a problem. A load average of 1 means that on average, there is at least one runnable task on the system. A load average above 1 simply means that there are more runnable tasks than there are CPUs to run them, which is not uncommon on a modern multi-core system. If you're not experiencing any other issues or problems, it may not be necessary to take any action.

2
  • This is... very generic and not at all helpful unfortunately.
    – miniBill
    Apr 23, 2023 at 13:44
  • Yeah, probably. I did my best, though.
    – mhadidg
    Apr 23, 2023 at 15:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .