Why is my CPU usage always 100%?

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.