Operations 15 min read

Do You Really Understand Linux’s free Command and Cache Behavior?

This article demystifies the Linux free command, explains the distinction between buffer and page caches, shows how various caches are reclaimed—or not—through practical tests with tmpfs, shared memory, and mmap, and provides actionable tips for accurately interpreting memory usage on RHEL 6 systems.

Efficient Ops
Efficient Ops
Efficient Ops
Do You Really Understand Linux’s free Command and Cache Behavior?

You Really Understand Linux’s free Command?

In Linux we often use the

free

command to view memory usage. On a RHEL6 system the default output shows values in kilobytes, which can look huge on a 128 GB server. Many users have only a superficial understanding of this output.

Unaware: sees large used memory and wonders why Linux “eats” memory. Thinks they understand: assumes most memory is free because buffers/cache can be reclaimed. Really understands: admits they cannot judge memory adequacy from free alone.

Most people fall into the second category, believing that buffers and cached memory are always reclaimable under pressure. Is that really true?

What Is Buffer/Cache?

In Linux memory management, buffer refers to the Buffer Cache, while cache refers to the Page Cache.

Historically, buffers cached writes to block devices, and cache cached reads from block devices.

Modern kernels treat them differently: page cache stores cached file pages, while buffer cache handles block‑device specific caching.

How Is Cache Reclaimed?

When memory is low, the kernel frees cache pages. The

/proc/sys/vm/drop_caches

interface can be used to trigger reclamation manually:

<code>echo 1 > /proc/sys/vm/drop_caches   # free pagecache

echo 2 > /proc/sys/vm/drop_caches   # free slab objects (dentries, inodes)

echo 3 > /proc/sys/vm/drop_caches   # free both pagecache and slab
</code>

Clearing cache incurs I/O cost because dirty pages must be written back before they can be released.

Cache That Cannot Be Reclaimed

tmpfs

Files stored in a tmpfs (e.g.,

/dev/shm

) occupy page cache and are not freed until the files are removed.

Shared Memory (shm)

Shared memory created via

shmget

also uses tmpfs under the hood. The following test program allocates ~2 GB of shared memory, writes to it, and exits without removing the segment:

<code>#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <string.h>

#define MEMSIZE 2048*1024*1023

int main() {
    int shmid = shmget(IPC_PRIVATE, MEMSIZE, 0600);
    if (shmid < 0) { perror("shmget"); exit(1); }
    // ... attach, write, fork, etc.
    return 0;
}
</code>

After the program runs, the cached memory increases and remains until the segment is removed with

shmctl IPC_RMID

or

ipcrm

.

mmap with MAP_SHARED

Memory mapped with

MAP_SHARED

also resides in cache. A test program creates a 2 GB file, maps it, zeroes the region, sleeps, then unmaps:

<code>#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>

#define MEMSIZE 1024*1024*1023*2
#define MPFILE "./mmapfile"

int main() {
    int fd = open(MPFILE, O_RDWR);
    void *ptr = mmap(NULL, MEMSIZE, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANON, fd, 0);
    bzero(ptr, MEMSIZE);
    sleep(100);
    munmap(ptr, MEMSIZE);
    close(fd);
    return 0;
}
</code>

During execution the cached memory grows and is only released after

munmap

finishes.

Key Takeaways

Reclaiming cache can spike I/O because dirty pages must be written back. Files in tmpfs occupy cache and are not freed until the files are deleted. Shared memory segments remain in cache until explicitly removed. MAP_SHARED mmap regions stay in cache until the mapping is unmapped. Both shm and MAP_SHARED mmap rely on tmpfs, so their memory is counted as cache.

Understanding these details moves you from a superficial view of

free

to a deeper grasp of Linux memory usage.

Cachememory managementLinuxMMAPshared memorytmpfsfree command
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.