Why is my CPU usage always 100%?
An investigation into a Chumby 8 device reporting 100% CPU usage reveals that the culprit was not actual load but a misbehaving hardware timer and under-documented SoC quirks, which confused the Linux kernel’s accounting. Commenters dig into how timers should be designed and read safely, why multiple register reads or capture registers are used as workarounds, and how such hardware bugs undermine portability and power management features. The thread broadens into how modern systems idle CPUs, why tools can misreport utilization, and the practical impact of misleading metrics on diagnostics and user trust.
Hardware timer bug and workaround
- Discussion centers on a buggy Marvell timer used in an old 32-bit SoC (e.g., Chumby-era hardware) that misreports time and thus CPU usage.
- The timer uses a capture register; a write-then-delay-then-read sequence is required, but documentation is vague.
- Vendor docs mention the request taking “up to three timer clock cycles” and possibly longer on a “slow clock,” implying the need for multiple reads or a delay.
- Explanation of correct timer design: either a synchronous counter, or a capture register with guaranteed completion or a “valid” flag; this hardware apparently got that wrong.
Debate over fix strategies and portability
- Existing forks read the capture register 3–5 times; the article chose 4 as a compromise and to match vendor practice.
- Some argue this isn’t portable across revisions, speeds, or different SoCs; others note this is already extremely hardware-specific code, so portability is limited anyway.
- Multiple reads may be better than a CPU-only delay because register reads are tied to the timer/peripheral clock, not CPU clock.
- An alternative proposed: bypass capture and repeatedly read the timer directly until two consecutive reads match; simple, fast, and common for counters with modest frequency.
CPU utilization, idling, and scheduling
- Clarification that “CPU at 100%” is only desirable when there is real work; otherwise it’s just a heater.
- Modern systems use HLT/idle instructions, interrupts, and timer coalescing so CPUs can sleep between bursts of work.
- Multi-core and heterogeneous-core designs allow some cores to be fully off while others handle background tasks; “race to idle” is preferred over running slowly at partial load.
Resource usage, Electron, and “wasted” memory
- Tangent on the misuse of “unused memory is wasted memory” to justify heavy apps; OS caches vs genuine bloat are distinguished.
- Debate over Electron: some say its overhead is overblown compared to browsers; others stress it is literally another browser instance and costly on low-RAM systems.
- Strong criticism of modern web-stacked UIs vs lean native toolkits, especially for always-on tray apps.
Misreporting, debugging, and war stories
- Several anecdotes about misinterpreting “System Idle” as a real process, Windows and HDD/NVMe busy indicators being wrong, and CPU or network bugs being blamed on hardware.
- Stories of badly written software (busy loops instead of sleep, synchronized servlets, overcomplicated Java workflows) causing high load and misguided hardware upgrades.
- Some note that “cosmetic” counter bugs can still have real effects when higher-level power or scheduling logic trusts those counters.