logo
CHEATSHEETSTOOLSABOUT中文

shmem vs tmpfs

In Linux, shmem (Shared Memory) and tmpfs refer to two aspects of the exact same underlying kernel mechanism.

The cleanest distinction is:

  • shmem is the internal kernel subsystem (and page cache infrastructure) that manages volatile, swap-backed memory pages.
  • tmpfs is the user-facing RAM filesystem driver mounted by the OS to expose that shared memory abstraction as a standard directory.

In the Linux kernel source code, both live in the same file: mm/shmem.c.

How They Relate Architecturally

In the Linux kernel, shmem is the foundation, and tmpfs is a wrapper layer over it:

      ┌─────────────────────────────────────────┐
      │          Userspace Applications         │
      └────┬──────────────────────────────┬─────┘
           │                              │
           │ POSIX / SysV IPC             │ File Operations
           │ (shm_open, shmget)           │ (open, read, write)
           ▼                              ▼
    ┌──────────────────┐           ┌──────────────────┐
    │ Internal shmem   │           │ User-Visible     │
    │ Mount            │           │ tmpfs Mounts     │
    │ (Unlinked Inodes)│           │ (/dev/shm, /tmp) │
    └────────┬─────────┘           └────────┬─────────┘
             │                              │
             └──────────────┬───────────────┘
                            ▼
                ┌───────────────────────┐
                │    Kernel mm/shmem    │
                │ (Page Cache + Swap)   │
                └───────────────────────┘

When you inspect mm/shmem.c in the Linux kernel tree, you will literally see the filesystem registration defined as:

static struct file_system_type shmem_fs_type = {
    .owner      = THIS_MODULE,
    .name       = "tmpfs",          /* Register name */
    .init_fs_context = shmem_init_fs_context,
    ...
};

Key Differences in Usage & Context

While they share the same engine, the terms are used differently depending on where you look in the system:

Context shmem tmpfs
System Visibility Internal kernel memory accounting (Shmem entry in /proc/meminfo). User-visible mounted filesystems (df -h, showing mount points like /dev/shm or /tmp).
Kernel Config Always built into the kernel, regardless of options (used for anonymous mmap(MAP_SHARED), System V IPC). Can be disabled at build time via CONFIG_TMPFS (though almost every distribution enables it).
Primary Access Point IPC APIs (shm_open, shmget, shared mmap). File system utilities (mkdir, cp, touch inside /tmp or /dev/shm).

The Internal shmem Mount vs. User tmpfs Mounts

  1. Kernel Internal Mount: The kernel secretly maintains an invisible, internal shmem mount. When you create shared anonymous memory (via mmap(..., MAP_SHARED | MAP_ANONYMOUS, ...) or System V shmget), the kernel behind the scenes creates an unlinked file inside this internal shmem subsystem.
  2. User Mounts (tmpfs): When glibc executes POSIX shm_open(), or when your init system mounts /tmp or /dev/shm, it simply creates a user-visible tmpfs filesystem instance over that same shmem subsystem.

Summary

  • Are they equivalent? Functionally, yes. tmpfs is just the filesystem interface built on top of the kernel's shmem page management subsystem.
  • Memory source: Both store data in the Linux Page Cache and can be swapped out to disk swap space if the system comes under memory pressure.
Loading...