Right, let’s talk about /proc/meminfo. You’ve probably run free -h and stared at the numbers, feeling a mix of confusion and vague dread. Is my system about to fall over? Why is “free” memory so low? Is it time to panic-buy more RAM? The free command is just a pretty (well, okay) interface for the raw, glorious data in /proc/meminfo. This file is the kernel’s unvarnished, slightly chaotic confession about its current memory state. It doesn’t care about your feelings. It just reports the facts.

Think of it not as a simple spreadsheet, but as a detailed breakdown of a very busy, slightly eccentric librarian’s system (the kernel). Some books (memory pages) are on the desk, ready for immediate use. Some are on shelves, neatly sorted (cached). Some are checked out but haven’t been touched in weeks (inactive). Our job is to understand the librarian’s filing system.

Let’s crack it open and see what we’re dealing with.

cat /proc/meminfo

You’ll get a wall of text with a bunch of entries. We’re going to focus on the headliners. The first thing you’ll see is the big one.

MemTotal: The Lie You’re Told at Boot

MemTotal is the first number you see, and it’s the first thing that will confuse you. It is not the total amount of physical RAM chips installed in your machine. Go on, try it. Add up the numbers from dmidecode or look at your BIOS; you’ll find a discrepancy of anywhere from几十MB to a few hundred.

Why? The kernel isn’t stealing your RAM for a secret project (mostly). On x86 systems, the kernel permanently reserves a portion of the physical address space for its own crucial functions. This includes the kernel’s own code and data structures, but the big ticket item is mapping your hardware devices (like your GPU’s memory) into the kernel’s address space so it can talk to them. This reserved space is not available for general-purpose allocation, so MemTotal shows you what’s left over for the rest of us to play with. It’s the “user-addressable” RAM.

MemFree: The Most Useless Metric in the World

MemFree is exactly what it sounds like: memory that is completely, totally, 100% unused. It’s pristine, untouched, and sitting idle. And on any healthy Linux system, this number should be very low. Like, “is-this-even-on?” low.

If you see a high MemFree value, it doesn’t mean your system is healthy; it probably means your system is underutilized or an application just freed a gigantic chunk of memory. The Linux kernel is a hoarder, but a smart one. It believes that unused RAM is wasted RAM. So, it takes your free memory and uses it for two incredibly useful things: Buffers and Cached. Letting memory sit idle in MemFree is like having a supercomputer and only using it to play Solitaire.

Buffers vs. Cached: The Kernel’s Filing System

This is where people’s eyes glaze over, but it’s actually simple once you get the analogy.

Buffers are temporary holding pens for data that’s on its way to or from a block device (think: disks). When the kernel wants to write something to disk, it doesn’t do it one byte at a time. It collects data in memory until it has a nice, efficient chunk to write. That in-memory collection is a Buffer. It’s transient. It’s raw. It’s the “outbox” for disk writes and the “inbox” for reads that haven’t yet been sorted.

Cached is where the kernel gets clever. Whenever it reads something from the disk (a program binary, a library, a log file, a database row), it keeps a copy in memory. Why? Because reading from RAM is about a thousand times faster than reading from even the fastest SSD. If that same data is requested again, bam, it’s served instantly from the Cached memory instead of waiting for the disk. This is the page cache, and it’s the single biggest reason Linux feels so fast. It’s the librarian having your favorite book already on the desk because you ask for it every day.

Here’s a dirty secret: there’s no real technical difference between “Cached” memory and “Free” memory. The kernel can abandon any page in the Cached pool instantly if an application needs the RAM. This is a key insight. Cached memory is available memory.

Available: The Number You Actually Care About

This is the star of the show. MemAvailable (introduced around kernel 3.14) is the kernel’s best estimate of how much memory is truly available for starting new applications without having to resort to swapping.

It calculates this by looking not just at MemFree, but also at the parts of the page cache (Cached) and other internal caches that are deemed “reclaimable” on short notice—meaning they can be freed up with minimal cost (like dropping clean, read-only cached files). It even includes some of the Buffers space.

This is the number you should watch on a production server. This is the number your monitoring system should alert on. If MemAvailable gets low, then you can start to worry. A simple way to check it is:

grep MemAvailable /proc/meminfo

Or use the more human-friendly free command, which now incorporates this wisdom:

free -h

Look for the available column in the Mem: row. That’s your truth.

The Big Picture: Why This All Matters

So, let’s say you run free -h and you see:

               total        used        free      shared  buff/cache   available
Mem:            15Gi       9.2Gi       1.1Gi       512Mi       5.4Gi       5.0Gi

A novice panics: “I’m using 9.2Gi of 15Gi! I’m at 60% capacity!” But you, now, are not a novice. You see the truth. You have 5.4Gi tied up in buff/cache, which is acting as a massive speed boost. Most importantly, you see you have a whopping 5.0Gi available. Your system is perfectly healthy, sitting pretty with resources to spare. The kernel is doing its job perfectly.

The design choice to aggressively cache isn’t questionable; it’s brilliant. The questionable choice was ever presenting MemFree as a meaningful metric on its own. MemAvailable is the apology for that earlier oversight. Use it.