Decoding htop: What Load Average, Uptime, and Task Counts Actually Mean

A deep walkthrough of every field in htop and top, aimed at demystifying metrics that even experienced Linux users misread. The author traces each value back to its source in the /proc filesystem — uptime comes from /proc/uptime, load figures from /proc/loadavg — and uses strace to show exactly which files the underlying tools open. The formatted output of commands like uptime exists mostly for human readability; the raw numbers are what scripts consume.

The centerpiece is load average, which is widely misunderstood as a direct CPU-percentage indicator. It is actually the count of processes that are running or waiting to run, plus those blocked in uninterruptible states (typically disk or network I/O). Because I/O-bound processes inflate the number without consuming CPU, high load can coexist with an idle processor — which is why tools like mpstat are needed for true instantaneous utilization. The three figures aren’t clean 1/5/15-minute windows either; they’re exponentially damped moving averages, so the one-minute value still carries roughly 37% of older activity. A saturated single core reads 1.0, a saturated dual-core reads 2.0, so load should always be interpreted against the machine’s core count.

The piece also clears up smaller points of confusion: htop labels processes as ‘Tasks’ because that’s the kernel’s internal term, and it can optionally surface user threads (Shift+H) and kernel threads (Shift+K). The recurring lesson is that the readouts are convenient abstractions over kernel counters, and understanding what they actually measure is what separates guessing from diagnosis. The author even cites the Linux scheduler source, where a kernel comment cheerfully calls load average ‘a silly number’ that people nonetheless insist is important.