I recently upgraded my system and added 8 GB of RAM along with 250 GB of SSD (1TB HDD is in Optical Bay) to improve its performance. My laptop was total garbage, and it still is, but at least now, I can open 10 Chrome Tabs and 2 Text Editors without much pain in the ass.
After the fresh installation of Ubuntu, I noticed that while browsing, my laptop’s fan was making way too much noise. It was odd, as it never happened before, especially while browsing.
To check what’s going on, I did -
and got the following results -
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1053 root 20 0 0 0 0 S 100.0 0 95:13.18 kworker/0:1 2462 rishi 20 0 1460984 131336 70080 S 3.3 1.1 35:36.86 compiz
To be honest, I had no idea about what kworker was, but it was literally hogging the CPU usage, so I googled, and got the below answer from here
kworker is a placeholder process for kernel worker threads, which perform most of the actual processing for the kernel, especially in cases where there are interrupts, timers, I/O, etc. These typically correspond to the vast majority of any allocated “system” time to running processes.
Fortunately, a few days back, I was reading about the ACPI Modules (Advanced Configuration and Power Interface), and it reminded me of the list of ACPI Kernel modules, in which, one of them was related to the Bay (bay status).
What is ACPI?
I don’t know the exact definition, but it can be described as a way (bridge) through which an Operating System and Hardware communicates.
Anyway, Wikipedia says -
ACPI provides an open standard that operating systems can use to discover and configure computer hardware components, to perform power management by (for example) putting unused components to sleep, and to perform status monitoring.
Since I was using the DVD slot (Optical Bay/Drive) for my Hard Disk, I thought the issue might be related to the same thing, so I took it out, and BOOM. The issue got resolved!
Well, not actually.
It was a temporary solution, as inserting the caddy back into the slot made kworker go crazy, and the CPU usage got back to 100%.
Conclusion: Lots of ACPI interrupts.
Possible reason: Hard drive being used through the Optical bay, and since the issue had everything to do with the ACPI, which means, GPE was telling OS (via ACPI) that something is happening. Probably transfer of events via Embedded Controller to GPE in huge number, per second.
Now, to understand the issue, I started digging further.
$ ls /sys/firmware/acpi/interrupts/
There were lots of files like
gpe01, gpe02, gpe03... gpe0n. Separately
echoing every file would have taken a lot of time, although I checked around 5-10 files manually. For this task,
grep was what I needed.
$ cd /sys/firmware/acpi/interrupts/ $ grep '' -r
gpe7B: 0 invalid unmasked gpe0F: 0 EN enabled unmasked gpe03: 43946 STS enabled unmasked gpe3D: 0 invalid unmasked
The list was long, but I spotted that
gpe03 had the highest value. Since I’m not aware of these things, my best guess was that those numbers are the events which are and being sent through Embedded Controller (EC) to the Operating System. Yes, the numbers kept increasing. Anyway, I tried -
$ echo "disable" > gpe03
And to my surprise, it fixed the problem. The fan started slowing down, and eventually, it stopped making any noise.
The changes made to
gpe03 wasn’t permanent, so rebooting the system brought it back to its original state which ended up letting kworker eat the CPU.
I stumbled upon this post on Ask Ubuntu. The question was asked 7 years ago!
The solution was to add
@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe03 to
$ export EDITOR=vim $ sudo crontab -e
I edited the crontab by adding -
@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe03
If you forget to add newline at the end of
crontabfile, it won’t work.
It’s important to
sudo crontab -einstead of just
crontab -e. You need to be
rootto update changes in system files.