The box had no business being busy. It was a quiet little utility host, a couple of background daemons and not much else, and yet top showed it sitting at a steady chunk of CPU with nothing obvious to account for it. No single process stood out. The load was just there, spread thin and stubborn.
When the process list does not explain the CPU, the next stop is the kernel, and the fastest way to look is perf top. It samples what the CPU is actually executing, right now, across the whole system, kernel and userspace alike, and shows you the hottest symbols live. No instrumentation, no restart, you just run it and watch.
The top symbol was a kernel function down in the networking stack, something to do with route lookups and connection tracking. That is rarely where idle CPU hides on a quiet host, so it was a useful surprise. The story unwound from there. A misconfigured service was opening a fresh connection for every tiny piece of work instead of reusing one, hundreds of times a second, and every new connection meant the kernel doing the full dance of allocation, conntrack bookkeeping, and teardown. None of it showed up against any one process in top, because the cost was in the kernel on their behalf, smeared across system time.
The fix was at the application end, not the kernel: get the service to hold a connection open and reuse it, the way it was always meant to. The perf top listing went quiet, the system CPU dropped back to where it should have been, and the box returned to the boring idleness I had wanted from it.
The habit worth keeping is to reach for perf top the moment the process list and the CPU figures disagree. When top says the machine is busy but no process owns the work, the work is almost always in the kernel, done for somebody, and perf top will tell you which kernel path is the loud one in seconds. From there it is just detective work, but at least you are looking in the right room.