Hacktakes · Edition 1
Hacktakes · Edition 1 · July 4, 2026

What does "used RAM" actually mean? (writing a tiny htop)

System utilities wildly disagree on RAM usage because of how FreeBSD and ZFS handle caching, proving used memory is not a single, indisputable integer.

By Poppy Lin

Sparked by FreeBSD ate my RAM · discussion

We technically have plenty of seating available, that gentleman is just caching his winter wardrobe until a larger party actually needs the chairs.
We technically have plenty of seating available, that gentleman is just caching his winter wardrobe until a larger party actually needs the chairs.

Figuring out how to accurately measure RAM has baffled me for a while now. For years, my mental model was incredibly simple: you open htop, look at the little green bar at the top of the terminal, and if it’s at 99%, you panic. I assumed that used memory was a fundamental, objective truth that the operating system just knew and reported as a single, indisputable integer.

But this past week, I was reading a post recently about FreeBSD "eating" someone's RAM—and watching the ensuing panic in a Hacker News thread—and I realized my mental model was totally flawed. It turns out that if you look at the exact same FreeBSD server at the exact same time, tools like htop, top, and fastfetch will wildly disagree with each other about how much memory is actually being used.

How can three different system utilities fundamentally disagree on something as basic as RAM? (what exactly is happening under the hood??)

To figure this out, let's bypass the user interfaces entirely and look at the raw data! (I always find it easier to grasp these concepts by reading the raw terminal output of system commands).

The core confusion comes down to how FreeBSD and the ZFS filesystem handle caching. On a standard Linux box, memory used for caching files is usually neatly bucketed into buffers/cache.

← Back to Edition 1