One CPU core always showing 100%

[ghost]

I'm running TopHat 11 on Pop_OS! on an AMD Ryzen 7 6800H. Previously TopHat worked fine on my system and while this may be an issue on my end, I can't seem to figure it out.

TopHat is always reporting one CPU core out of 16 (8 hyperthreaded) always being at 100%, despite other tools like gnome-system-monitor and htop showing 1-2% usage.

I've set htop to not hide kernel threads and still I don't see hardly any usage... even TopHat itself doesn't actually show any application using much CPU.

[ghost]

Not sure if this is technically a me issue, but I think this is because however TopHat is getting info, it's the same as setting htop to include detailed usage, which shows that core with a gray full bar, and this seems linked to IRQs

[mattia-b89]

I have never had such kind of issue.
Is it still valid for you?

[webdevelopers-eu]

I set up the extension to show only CPU and Network metrics, but it still uses 11% of one CPU core at regular intervals according to atop and the extension shows one full bar all the time.

It seems the extension frequently polls stats from /proc/* (strace), causing it to do unnecessary work and drive up CPU load. My guess is that each refresh triggers a brief 100% CPU spike on one core as it processes all the data at once. The atop tool, which averages over one-second intervals, registers this as 11% usage due to the short burst <1s. However, the extension itself detects the momentary 100% load and displays a full bar.

Ideally, reading of all /proc/*/cpu,cmdline,stat files (in my case it reads 800+ files from /proc/ folder during each update) should occur only when the user clicks the tray icon to access information on demand, which would reduce the extension’s resource usage.

Additional optimizations could also help—for example, capturing the CPU state before any intensive processing starts might prevent unnecessary spikes to 100% CPU during the measurement itself. Alternatively, performing all non-CPU-intensive tasks first, then allowing a brief pause for cores to settle before capturing the CPU state with a low-impact method, could help achieve a more realistic view of CPU usage across cores without skew from the capture process itself.

[fflewddur]

@ghost, yes, TopHat includes IRQ usage in its process calculations, so what you're seeing is intentional. Do you know why one of your cores is constantly showing high IRQ usage?

@webdevelopers-eu, not quite. TopHat calculates usage over time (3 seconds by default, but this is user configurable) and TopHat itself certainly shouldn't be driving that much CPU usage. I would love to limit the /proc/* reads to only occur when the detail menus are displayed, but this creates a different problem: when I see a CPU or memory spike, I want to click on the menu to immediately see what caused it. But, /proc/* record counters are always incrementing for things like CPU usage and disk activity--this means we need to know the state of the CPU, say, 3 seconds ago, and compute how much it changed during that time period. If those details are only ready from /proc/* when the menu is open, then we need to wait for multiple polls of /proc/*, so the menu would be empty for a few seconds, and wouldn't reflect whatever usage drove the spike that caused me to look at it in the first place. I'm all ears if you have any ideas for how to more efficiently solve this problem.

[webdevelopers-eu]

@fflewddur, I understand your challenge now. I don’t have a definitive solution for this issue, but one idea that comes to mind is adding a checkbox option to disable the Top Processes pane.

I don't use this feature myself, as I don't monitor CPU usage that closely. When there is a spike, I usually know which task is responsible. If I don’t, I often have my terminal open and can quickly run atop or another tool when unexpected loads appear. Additionally, the spikes I look for are typically long-lasting, so waiting a few seconds for polling is not an issue. Tracking sudden CPU bursts with this extension might not be the primary use case for many users, so the trade-off may not be favorable for the majority.

And thank you—despite this issue, this remains my favorite resource monitoring extension out of all the others.