What Is Demand Paging?

Demand paging, sometimes called lazy allocation, is a memory management strategy where the operating system delays assigning a physical page frame to a virtual page until the program actually accesses that memory. This applies to both kernel-side vmalloc() allocations and user-space malloc() allocations. The allocator’s job at call time is only to reserve a range of virtual addresses; the real work of finding a physical page frame is postponed until it is genuinely needed.

Why Demand Paging Matters for Driver Developers

If you are working through our free Linux device drivers course, understanding demand paging changes how you think about memory usage. A large vmalloc() call that succeeds does not immediately consume physical RAM — RAM usage grows gradually as your driver actually reads or writes into the buffer. This has real consequences for how you size buffers and how you interpret memory usage tools while debugging.

The Hardware Side: MMU and TLB

Every virtual address your kernel code touches has to be translated into a physical address before the CPU can actually read or write memory. This translation is handled by the Memory Management Unit (MMU), a dedicated piece of hardware built into the CPU core.

To avoid walking page tables on every single memory access, the MMU keeps a small hardware cache of recent virtual-to-physical translations called the Translation Lookaside Buffer (TLB). If the translation is already cached, this is called a TLB hit, and the access completes immediately. If not, it is a TLB miss, and the MMU must walk the page tables to find the mapping.

What Happens When No Physical Page Exists Yet?

Here is the crucial part for demand paging: sometimes the page table walk itself fails to find a matching physical address, because — as with a fresh vmalloc() allocation — no physical page frame has been assigned yet. The MMU cannot resolve this on its own, so it raises a page fault exception, handing control to the kernel’s page fault handler, which runs in the context of the process that triggered the access.

The page fault handler requests a single physical page frame, at allocation order zero, from the kernel’s page (buddy system) allocator, and maps it into the faulting virtual address. From this point on, that specific page has real physical memory behind it — but only that one page, not the entire original allocation.

Demand Paging vs Immediate Allocation: A Comparison

Notice that kmalloc() and the low-level page allocator do not use demand paging — physical page frames are assigned immediately, because the buddy system’s freelists already map all usable physical RAM into the kernel’s low-memory region, making the assignment essentially free in terms of extra work.

A Small Demonstration: Observing Lazy Allocation

You can observe demand paging indirectly by comparing memory reported immediately after a large vmalloc() style allocation versus after the buffer is actually written to. Here is an original demo module for this lesson that touches memory in two separate stages so you can watch resident memory grow between them using /proc/meminfo.

#include <linux/init.h>
#include <linux/module.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>

#define EP_BIG_SIZE   (16 * 1024 * 1024)

static char *ep_bigbuf;

static int __init ep_demand_paging_demo_init(void)
{
    ep_bigbuf = vmalloc(EP_BIG_SIZE);
    if (!ep_bigbuf)
        return -ENOMEM;

    pr_info("ep_demo: 16MB reserved virtually, check /proc/meminfo now\n");
    ssleep(5);

    memset(ep_bigbuf, 0xAA, EP_BIG_SIZE);
    pr_info("ep_demo: buffer fully touched, physical pages now assigned\n");

    return 0;
}

static void __exit ep_demand_paging_demo_exit(void)
{
    vfree(ep_bigbuf);
    pr_info("ep_demo: buffer freed\n");
}

module_init(ep_demand_paging_demo_init);
module_exit(ep_demand_paging_demo_exit);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("EmbeddedPathashala demand paging demo");

Load the module and, during the five-second sleep window, watch memory usage in another terminal:

sudo insmod ep_demand_paging_demo.ko
watch -n 1 grep -E "MemFree|VmallocUsed" /proc/meminfo

Common Mistakes and Troubleshooting

Best Practices

Performance and Security Considerations

Performance: the first access to any demand-paged region costs extra time due to the page fault trap and handler execution. Subsequent accesses to the same page are fast, since the mapping is now cached in the TLB.

Security: because physical frames are assigned lazily and can come from anywhere in RAM, kernel code must never assume a fixed relationship between a vmalloc virtual address and any physical address, and must never leak raw virtual addresses that could aid attackers in probing kernel memory layout.

Summary and Key Takeaways

Conclusion

This lesson of our free Linux kernel development course explained how demand paging bridges the gap between a virtual memory reservation and real physical RAM, using the MMU, TLB, and the kernel’s page fault handler. Combined with the previous lesson on vmalloc(), vzalloc(), and kvmalloc(), you now have a solid, modern-kernel understanding of how kernel memory allocation truly works under the hood — a foundational skill for our free Linux device drivers course and free embedded systems course.

Frequently Asked Questions