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.
You Really Understand Linux’s free Command?
In Linux we often use the
freecommand 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_cachesinterface 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
shmgetalso 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_RMIDor
ipcrm.
mmap with MAP_SHARED
Memory mapped with
MAP_SHAREDalso 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
munmapfinishes.
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
freeto a deeper grasp of Linux memory usage.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.