Home
AI
Blog

Linux Memory Management: From malloc() to Physical RAM

basanta sapkota
How can malloc() hand you memory that doesn’t seem to exist yet? That odd little trick is one of the first things that makes Linux memory management feel slightly magical. You ask for bytes in user space, get back a pointer, and only later does the kernel, the MMU, and physical RAM get dragged into the story.

If you write C, debug memory-heavy services, or just like knowing what your machine is actually doing, this path matters. Linux memory management sits between your code and the hardware, translating a simple malloc() call into virtual pages, page tables, page faults, and eventually physical RAM. Once you see the layers, tools like top, pmap, /proc/meminfo, and even OOM logs make a lot more sense.

Key Takeaways

  • malloc() does not usually hand you raw physical RAM. It returns a pointer in your process's virtual address space.
  • Linux uses virtual memory so each process sees an isolated address space, even though all processes share the same physical machine.
  • Memory is managed in pages, typically 4 KB on common Linux systems, and page tables map virtual pages to physical page frames.
  • Small allocations often come from the heap via brk()/sbrk()-style growth, while larger ones are often backed by mmap().
  • Linux commonly uses optimistic allocation or overcommit, so a successful malloc() does not always mean RAM is physically reserved yet.
  • Physical backing often happens on first access through demand paging, which triggers a page fault and allocates a real page frame.
  • When RAM runs low, Linux may use swap, and in bad cases the OOM killer may terminate processes.
  • Metrics like VSZ and RSS are different: VSZ is virtual memory size, while RSS is the portion currently resident in RAM.

Linux Memory Management Starts With Virtual Memory

The first thing to understand is that your process does not work with physical addresses directly. It works with virtual addresses. As the EPITA Gistre article explains, each process gets the illusion of its own clean, private address space. That isolation is a huge deal for security and stability.

On a 64-bit Linux system, the theoretical virtual address space can be enormous, though practical limits apply. Inside that space, memory is split into familiar regions:

  • Text segment for code
  • Data segment for globals and statics
  • Heap for dynamic allocation
  • Stack for function calls and local variables
  • Mapped regions for shared libraries, files, and anonymous mappings

So when malloc() returns a pointer like 0x5555..., that is a virtual address, not a literal spot in RAM.

For a deeper kernel-side view, the Linux kernel documentation on page tables is worth bookmarking.

From malloc() to Linux Heap Allocation

At user-space level, malloc() is provided by libc, not by the kernel directly. In glibc, the allocator manages free chunks, reuses old allocations when possible, and only asks the kernel for more memory when it has to.

A simple example looks harmless enough:

# include <stdio.h>
# include <stdlib.h>

int main(void) {
    int *x = malloc(sizeof(int));
    if (!x) {
        perror("malloc");
        return 1;
    }

    *x = 42;
    printf("%d\n", *x);
    free(x);
    return 0;
}

But under the hood, Linux memory management may take different routes depending on allocation size.

brk() and the Traditional Heap

Historically, heap growth was done with brk() and sbrk(). These adjust the program break, which marks the end of the process data segment. This is efficient for many small allocations, but it has limits:

  • the heap is basically one growing region
  • fragmentation becomes annoying
  • releasing memory back to the OS is less flexible

mmap() for Larger or Separate Allocations

Modern allocators often use mmap() for larger allocations. The mallopt(3) man page notes that glibc uses a dynamic mmap threshold, with an initial value of 128 KB by default. Allocations at or above that threshold may be served with mmap() instead of growing the heap.

That matters because mmap() allocations can often be returned to the system more cleanly than ordinary heap chunks.

Example:

# include <sys/mman.h>
# include <stdio.h>
# include <unistd.h>

int main(void) {
    size_t len = 4096;
    void *p = mmap(NULL, len, PROT_READ | PROT_WRITE,
                   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

    if (p == MAP_FAILED) {
        perror("mmap");
        return 1;
    }

    ((char *)p)[0] = 'A';
    munmap(p, len);
    return 0;
}

Linux Pages, Page Tables, and Physical RAM

Linux memory management works in pages, not arbitrary byte-sized physical chunks. The sources you provided, along with Linux Journal, point out that page size is typically 4 KB on many systems.

Here’s the chain:

  1. Your process accesses a virtual address
  2. The CPU’s MMU looks up the mapping
  3. Page tables translate virtual pages to physical page frames
  4. The CPU may cache recent translations in the TLB for speed
  5. If the page is not present, a page fault occurs

Linux Journal also notes that modern 64-bit Linux systems generally use multi-level page tables, commonly a four-level hierarchy, because a single giant page table would waste too much memory.

And yes, this is why memory access is fast most of the time but occasionally expensive. The fast path hits cached translations. The slow path falls into page table walks or faults.

Why malloc() Can Succeed Before RAM Exists

This is the part that confuses people, and honestly, it should. A successful malloc() often does not mean Linux has already assigned physical RAM to every requested byte.

The malloc(3) man page states that Linux follows an optimistic memory allocation strategy by default. In plain English, Linux may promise memory first and worry about actual backing later. Stack Overflow discussions and the EPITA article both describe this as lazy allocation or demand paging.

So what happens?

  • malloc() reserves virtual address space
  • physical memory may remain unassigned
  • on first write or read, the kernel handles the page fault
  • then a real page frame may be attached

That’s why a program can sometimes allocate more memory than the installed RAM appears to allow. Virtual memory, overcommit, and swap make that possible.

Swap, Overcommit, and the OOM Killer in Linux Memory Management

When RAM gets tight, Linux has a few options.

Swap Extends Available Backing Storage

Linux can move less-used pages out to swap, which may be a swap partition or swap file. Linux Journal notes that the swappiness parameter ranges from 0 to 100, controlling how aggressively the kernel prefers swapping behavior.

Useful commands:

cat /proc/sys/vm/swappiness
free -m
vmstat 2
swapon -s

Swap helps, but it is much slower than RAM. On SSDs it’s less painful than old spinning disks, but still nowhere near real memory speed.

Overcommit Changes the Rules

Linux also supports different overcommit policies. This is why malloc() may succeed even when the machine cannot back everything immediately. In practice, this improves utilization, but it also means memory failure can happen later, at touch time, not allocation time.

When Things Go Really Bad: OOM

If the system cannot satisfy memory demands, Linux may invoke the OOM killer and terminate a process to recover memory.

Check logs with:

dmesg | grep -i oom

Not fun. But very real.

How to Observe Linux Memory Management in Practice

If you want to connect theory to a running process, these tools help a lot:

  • top or htop for live memory pressure
  • free -m for system-level RAM and swap
  • pmap <pid> for per-process mappings
  • /proc/<pid>/maps for mapped regions
  • /proc/meminfo for system memory details
  • ps aux for VSZ and RSS

A useful distinction from Baeldung’s explanation:

  • VSZ = total virtual memory size a process can access
  • RSS = the amount currently resident in physical RAM

RSS is usually more useful than VSZ when you want to know how much real memory a process is actively holding, though even RSS can mislead when shared mappings are involved.

If you want a related read, our post on Linux page cache explained: why your RAM isn’t really “free” pairs nicely with this topic. And if you’re dealing with large multi-socket systems, NUMA architecture explained for developers adds another layer that matters a lot.

A Mental Model for Linux Memory Management

If i had to compress the whole thing into one practical model, it’d be this:

  • malloc() manages user-space allocation
  • glibc may request memory with brk() or mmap()
  • Linux creates or updates virtual mappings
  • the MMU and page tables translate addresses
  • actual physical RAM may only appear on first access
  • swap and overcommit stretch the illusion
  • and when pressure gets severe, the OOM killer ends the argument

That’s the journey from malloc() to physical RAM. Not one step, but a stack of abstractions. And honestly, that stack is why modern systems are usable at all.

Conclusion

Linux memory management is one of those topics that looks simple from the API and wonderfully messy underneath. malloc() feels like a basic library call, but it sits on top of virtual memory, page tables, heap management, mmap(), demand paging, swap, and kernel policy decisions.

Once you understand that chain, weird behavior starts looking normal. Huge VSZ numbers. Small RSS values. malloc() succeeding “too easily.” Sudden OOM kills. It all fits.

Try watching a real process with pmap, top, and /proc/<pid>/maps while allocating memory in a small C program. That’s where this topic really clicks. And if you’ve got your own favorite memory-debugging workflow, leave a comment. I’m always curious how other people inspect this stuff in the wild.

Sources

  1. EPITA Gistre Blog, Understanding memory management within Linux: from malloc() to /proc
    https://blog.gistre.epita.fr/posts/matheo.crespel-2025-06-12-memory_management/

  2. Linux Journal, Linux Memory Management: Understanding Page Tables, Swapping, and Memory Allocation
    https://www.linuxjournal.com/content/linux-memory-management-understanding-page-tables-swapping-and-memory-allocation

  3. Linux man-pages, malloc(3)
    https://man7.org/linux/man-pages/man3/malloc.3.html

  4. Linux man-pages, mallopt(3)
    https://man7.org/linux/man-pages/man3/mallopt.3.html

  5. Linux Kernel Documentation, Page Tables
    https://docs.kernel.org/mm/page_tables.html

  6. Stack Overflow, Malloc allocates memory more than RAM
    https://stackoverflow.com/questions/7504139/malloc-allocates-memory-more-than-ram

  7. Baeldung, Process Memory Management in Linux
    https://www.baeldung.com/linux/process-memory-management

  8. Reddit r/osdev discussion, A very basic question: is free space management for virtual memory...
    https://www.reddit.com/r/osdev/comments/xnk8xn/a_very_basic_question_is_free_space_management/

  9. OSDev Wiki, Memory Allocation
    https://wiki.osdev.org/Memory_Allocation

Post a Comment