this post was submitted on 27 Oct 2024
161 points (100.0% liked)

Linux

48742 readers
1144 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
161
How to find what's eating 100% of just one core? (lemmy.ca)
submitted 2 months ago by [email protected] to c/[email protected]
27 comments fedilink hide all child comments
 

From time to time, often after I've restored from sleep or finished playing a Steam game, one of my CPU cores is pinned at 100% with no indication of what might be doing it. Running htop, btop, or GNOME system monitor all show the same thing: CPU0 at 100% while the rest are doing near-nothing, and no process in particular seems to be using those resources.

If I restart, it's back to normal, and sometimes I can play a game in Steam or let the computer go to sleep and it doesn't do this, but it happens often enough that's annoying/confusing so I'd like to know if there's a way to either (a) diagnose which processes are using which CPU cores, or (b) somehow "reset" the checking of these values to make sure that something's not just being misreported.

This is a desktop system running Arch & GNOME.

all 28 comments
sorted by: hot top controversial new old
[–] [email protected] 88 points 2 months ago (1 children)

Show kernel threads, it's a setting in the htop config menu that is off by default.

[–] [email protected] 50 points 2 months ago* (last edited 2 months ago) (4 children)

There it is! Thank you! It's a process owned by root called kworker/0:0+kacpid. Any idea what that is?

[Edit 1] Interestingly, I can't even kill -9 it.

[Edit 2] With kworker kacpid to work with, I did a quick search and found this SO page that has some interesting information that I only partially understand, but the following worked like a charm:

# grep -Ev "^[ ]*0" /sys/firmware/acpi/interrupts/gpe?? | sort --field-separator=: --key=2 --numeric --reverse | head -1
/sys/firmware/acpi/interrupts/gpe09:11131050     STS enabled      unmasked
# echo disable > /sys/firmware/acpi/interrupts/gpe09

It's not clear to me what an interrupt is or whether this gpe09 value is meant to be persistent across reboots, or why this only seems to be happening in the last couple months, but if I can make it go away by running the above from time to time, I guess it's alright?

[–] [email protected] 47 points 2 months ago* (last edited 2 months ago) (1 children)

An interrupt is an input that can be triggered to interrupt normal execution. It is used for e. g. hardware devices to signal the processor something has happened that requires timely processing, so that real-time behavior can be achieved (for variable definitions of real-time). Interrupts can also be triggered by software, and this explanation is a gross oversimplification, but that information is what is most likely relevant and interesting for your case at this point.

The commands you posted will sort the interrupts and output the one with the highest count (via head -1), thereby determining the interrupt that gets triggered the most. It will then disable that interrupt via the user-space interface to the ACPI interrupts.

One of the goals of ACPI is to provide a kind of general hardware abstraction without knowing the particular details about each and every hardware device. This is facilitated by offering (among other things), general purpose events - GPEs. One of these GPEs is being triggered a lot, and the processing of that interrupt is what causes your CPU spikes.

The changes you made will not persist after a reboot.

Since this is handled by kworker, you could try and investigate further via the workqueue tools: https://github.com/torvalds/linux/tree/master/tools/workqueue

In general, Linux will detect if excessive GPEs are generated (look for the term "GPE storm" in your kernel log) and stop handling the interrupts by switching to polling. If that happens, or if the interrupts are manually disabled, the system might not react to certain events in a timely manner. What that means for each particular case depends on what the interrupts are being responsible for - hard to tell without additional details.

[–] [email protected] 3 points 2 months ago (1 children)

the system might not react to certain events in a timely manner.

But still react? Resource for read more?

[–] [email protected] 4 points 2 months ago

I'll post some links, but it's a pretty busy week for me already, so give me some time.

[–] [email protected] 45 points 2 months ago (1 children)

That's a kernel worker for ACPI. It sounds like you may have a driver for something that is misbehaving.

[–] [email protected] 1 points 2 months ago

More likely is the device firmware and you likely can't fix that.

[–] [email protected] 22 points 2 months ago

You can’t kill that because it’s a kernel thread. They are not like normal process; these objects are part of the operating system and terminating such a thread can cause in stability.

[–] [email protected] 11 points 2 months ago

To me it sounds like your root cause is either a driver problem or your hardware is misbehaving a little bit in a way the driver doesn’t expect, firing a lot of interrupts that shouldn’t normally happen.

If this seems to resolve your issue, I wouldn’t lose any sleep over it. I would think my hardware is a little bit weird or there’s a bug somewhere in the driver for it. You can also try different kernel versions if your distribution gives you the option, because kernels come with different versions of drivers.

[–] [email protected] 25 points 2 months ago

I blame Daniel

[–] [email protected] 18 points 2 months ago (5 children)

It’s the Linux version of steam taking advantage of idle time to process shaders. It’s a critical part of making all those proton launched games working right. I wish it had better control for when to run it but it is what it is.

[–] [email protected] 9 points 2 months ago

Just as a PSA, the feature is currently somewhat bugged and really should be avoided. For anything that's not a low-end PC, your machine can handle the compilation during runtime easily and do it much faster.

For low-ends, it compiles so many unnecessary shaders (such as all workshop content that you might not even have), it often takes 10x longer to compile everything (which you have to recompile on every driver or game cache update) than just playing the game and watching a replay first or something.

[–] cheviotveneer 8 points 2 months ago

If this were true, OP would see Steam as a user-mode process taking up the CPU time. Since the OP image is sorted by CPU time and the process isn't visible, it's gotta be those kernel threads that aren't displayed by default.

[–] [email protected] 6 points 2 months ago (1 children)

Why does it only use one core?

[–] [email protected] 9 points 2 months ago

And why would the process not show up in top?

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago)

"Critical" as in not really needed.

It is very bugged and constantly runs even if it isn't doing anything. It will also max out your disk IO for hours at a time with an HDD for larger game storage.

I have had it off for 1.5 years across 3 OS installs and have never had a problem with stuttering or shader related problems in that time. It is really not needed anymore for 95% of games since the Linux async solutions were merged.

Maybe if one uses severely out of date kernels it is critical

[–] [email protected] 16 points 2 months ago* (last edited 2 months ago) (2 children)

I have been fighting with this for a long time, do you have an external monitor? I find this happens if I wake from light-sleep (not hibernation) while an external monitor is plugged in.

One of my ACPI interrupts just goes off the charts.

[–] [email protected] 11 points 2 months ago (1 children)

In one of the other comments, we worked out that it was definitely something to do with ACPI, but yes I do have an external monitor. This is a desktop system.

Disabling the interrupt did the job, but I don't know why it's happening. If this is related to the monitor, could this be an Nvidia thing?

[–] [email protected] 5 points 2 months ago* (last edited 2 months ago)

I have a pretty old integrated Intel GPU. Happens to my Thinkpad pretty regularly.

[–] [email protected] 1 points 2 months ago

Similar thing happens to me with my two monitor setup. No problem when I use single monitor. No problem when I use two monitor. However when I plugged out the second monitor or switch to single monitor with my script, the CPU starts doing random spikes on single cores in short intervals. Only a reboot fixes this.

[–] [email protected] 9 points 1 month ago (2 children)

Another quick tip for htop: the red color in the CPU bar means kernel stuff. In my case it was an issue with interrupts

[–] [email protected] 4 points 1 month ago (1 children)

Where can I learn what each colors means? Is it buried in man htop somewhere? Or in a website?

[–] [email protected] 6 points 1 month ago* (last edited 1 month ago)

F1 or h while in htop should show the guide

[–] [email protected] 3 points 1 month ago

I had no idea! Thanks for the tip.

[–] [email protected] 3 points 2 months ago

I've had this happen with AI stuff that runs in a Python venv. It only happens with apps that use multi threading, and usually when something is interrupted in an unintended or unaccounted for way. I usually see it when I start screwing with code stuff, but also from changing the softmax settings during generation or crashing other stuff while hacking around. There may be a bug of some kind, but I think it likely has more to do with killing the root threading process and leaving an abandoned child that doesn't get handled by the kernel process scheduler in the standard way. If this happens I restart too.

[–] [email protected] 1 points 2 months ago (1 children)

Is this why people use Zen?

[–] [email protected] 3 points 2 months ago

No, it wouldn't make any sort of difference.