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.

  • Tenkard@lemmy.ml
    1·
    6 days ago

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

    • Daniel Quinn@lemmy.caOPEnglish
      1·
      8 days ago

      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?

      • scrion@lemmy.world
        1·
        8 days ago

        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.

  • TechnoCat@lemm.ee
    1·
    8 days ago

    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.

    • Daniel Quinn@lemmy.caOPEnglish
      1·
      8 days ago

      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?