Stop trusting your CPU usage metrics when they sit at 100 percent

Technical Briefing | 7/18/2026

You check your dashboard and see a CPU pegged at 100 percent. The natural reaction is to look for a runaway process, restart a service, or blame the developers for bad code. But I have seen this drive people crazy because the server feels responsive, load averages are low, and nothing is actually crashing. Sometimes the number lies to you because you are looking at the wrong kind of busy.

The kernel is just spinning its wheels

What is often happening here is that a process is stuck in a spinlock while waiting for a resource that just is not ready. The CPU core is technically executing instructions as fast as it can, but it is not doing any actual work. It is looping inside the kernel, checking a state that isn’t changing. This shows up as high system time in top, but it isn’t moving your request queues forward. That’s why your load average might stay deceptively healthy while your CPU metric looks like it is about to melt.

perf top -g -p <PID>

• Check if high system time correlates with increased context switches
• Look for excessive kernel functions in the perf report output
• Verify if the process is stuck in an uninterruptible sleep state during I/O waits
• Identify if your lock contention is caused by hardware interrupt storms

If you see a lot of time spent in functions like raw_spin_lock or similar kernel primitives, you have found your culprit. It is not an application performance issue; it is a resource contention issue. Instead of wasting time on profiling your app code, look at the hardware drivers or the kernel modules handling those locks. If you ignore this and keep throwing more cores at the box, you are just giving the kernel more room to spin in circles.