Why FreeBSD Memory Tools Disagree — and Why btop Gets It Wrong

A blogger migrating a server from Ubuntu to FreeBSD dug into why system monitors reported wildly different RAM usage for the same machine — fastfetch showed 82% used while btop showed just 7%. The root cause is that “used memory” has no single definition. FreeBSD’s virtual memory system sorts 4KiB pages into queues (active, inactive, laundry, wired, free), and much of what looks occupied is actually reclaimable: inactive pages can be dropped on demand, and the kernel aggressively caches disk data in RAM. On ZFS, the default filesystem, that caching happens through the Adaptive Replacement Cache (ARC), which lives in wired memory and shrinks automatically when applications need more room — so even “wired” isn’t fully locked.

Because there’s no canonical number, each tool picks its own heuristic. fastfetch counts free plus inactive plus cache as available; htop treats wired, active, and laundry as used; btop subtracts only active and wired from the total. Comparing them against a hand-written Python script that computed every heuristic side by side, the author found btop was the clear outlier. Reading its FreeBSD source revealed why: it pulls page counts straight from vm.stats.vm.*, including v_cache_count, which is effectively zero on modern FreeBSD, so its cached and available figures are misleading.

The practical takeaway echoes the classic “Linux ate my RAM” argument: unused RAM is wasted RAM, and a filesystem cache filling memory is a feature, not a leak. But it’s also a caution about trusting monitoring tools blindly — the same box can look 7% or 82% full depending entirely on which reclaimable pages a tool decides to call “used,” and at least one popular tool reports figures that don’t reflect how FreeBSD actually manages memory.