If you have ever written a Linux kernel module and reached for kmalloc() to grab a large buffer, you may have been surprised when the call simply failed for no obvious reason. This is one of the most frequently misunderstood corners of Linux kernel memory management, and it trips up beginners and experienced driver authors alike. In this lecture of our free Linux kernel development course, we untangle exactly why kmalloc() cannot hand out unlimited memory, what actually decides the ceiling, and how that ceiling has evolved on modern 6.x kernels.
free linux kernel development course
free linux device drivers course
free embedded systems course
MAX_ORDER
KMALLOC_MAX_SIZE
What You Will Learn
How PAGE_SIZE and MAX_ORDER combine to define the limit
The current KMALLOC_MAX_SIZE formula on kernel 6.x
Why the historic “4 MB rule of thumb” still mostly holds
What changed in the MAX_ORDER naming and semantics since 6.8
When to reach for vmalloc(), kvmalloc(), or CMA instead
Prerequisites
This lecture assumes you already understand the basics of the slab allocator (kmalloc(), kzalloc(), kfree()) covered earlier in this free Linux kernel programming course, and that you are comfortable building and loading a simple kernel module with insmod / rmmod. If either of those is new to you, go back to the earlier slab allocator lecture in this series first — the previous/next lecture links at the top and bottom of this page will take you there once published.
The Core Guarantee That Creates the Limit
Every allocation returned by kmalloc() comes with a promise: the memory is physically contiguous, not just virtually contiguous. That single guarantee is what makes kmalloc() fast and DMA-friendly, and it is also exactly what caps how much you can ask for in one call.
vmalloc() buffer
Virtually contiguous, physically scattered anywhere.
kmalloc() buffer
Virtually AND physically contiguous — a single unbroken block.
Because the underlying page allocator (often called the buddy system) can only produce a contiguous run of pages up to a certain size, kmalloc() inherits that same ceiling. There is no way around this without giving up physical contiguity entirely.
The Two Numbers That Decide the Ceiling
The maximum single-call allocation size is a function of exactly two kernel constants:
| Constant | Meaning | Typical value (x86_64 / ARM64, 4K pages) |
|---|---|---|
PAGE_SIZE |
Size of one hardware memory page | 4096 bytes (4 KB) |
MAX_ORDER |
Largest page-count “order” the buddy allocator will serve | 10 (kernel 6.8+ semantics) |
That 4 MB figure is not a magic number written directly into the source — it falls out of multiplying two independently configurable values together. Change the page size (as some ARM64 builds do, using 16 KB or 64 KB pages) or change MAX_ORDER for a given architecture, and the ceiling moves with them.
Note: Starting with Linux 6.8, the kernel changed how MAX_ORDER is interpreted. In older kernels, MAX_ORDER was one greater than the largest usable order (so the real limit was MAX_ORDER - 1). Since 6.8 the macro was cleaned up so that MAX_ORDER directly equals the largest usable order. If you are reading an older blog post or textbook that does the arithmetic with MAX_ORDER - 1, that is the pre-6.8 convention — the practical few-megabyte ceiling on typical hardware has not meaningfully changed, only the bookkeeping around the macro’s exact value did.
Where kmalloc() Actually Gets KMALLOC_MAX_SIZE From
In practice, kmalloc() does not directly consult MAX_ORDER on every call. The slab allocator pre-computes a constant, KMALLOC_MAX_SIZE, once at compile time, and every kmalloc() / kzalloc() request is checked against it. On current kernels this constant is capped at the smaller of two values: an architecture-independent 32 MB ceiling, or whatever the page-order math above works out to for that architecture and page size. On a standard x86_64 or ARM64 system with 4 KB pages, the page-order math produces the smaller number, so the effective limit remains a few megabytes, not 32 MB.
Rule of thumb for this free Linux device drivers course: treat anything above roughly one page (4 KB) as “large” for kmalloc() purposes, and treat anything approaching a few megabytes as “essentially the ceiling.” Actually hitting the wall in a real driver is rare — if you are getting close, that is usually a sign you should not be using kmalloc() for that buffer at all.
Why Not Just Raise the Limit?
It is tempting to think the kernel could simply allow a bigger single allocation. In reality, physically contiguous memory becomes exponentially harder to find as a system runs longer. Every driver load, unload, and page cache eviction leaves behind small physically scattered free pages — a phenomenon called external fragmentation. A running system can easily have gigabytes of free RAM overall while being unable to satisfy a single 8 MB physically contiguous request, simply because no run of 2048 consecutive physical pages happens to be free at that moment.
| Allocator | Physically contiguous? | Practical size ceiling | Best for |
|---|---|---|---|
kmalloc() / kzalloc() |
Yes | A few MB (KMALLOC_MAX_SIZE) | Small buffers, DMA-safe memory |
vmalloc() / vzalloc() |
No | Limited mainly by available virtual address space | Large buffers that never touch DMA |
kvmalloc() / kvzalloc() |
Tries kmalloc first, falls back | Same as vmalloc on fallback | Size-unpredictable buffers |
CMA (dma_alloc_coherent) |
Yes | Configurable reserved region, can be tens of MB+ | Large DMA buffers (video, capture) |
Real-World Use Cases
- Network drivers: per-packet buffers are small and fit comfortably inside the kmalloc ceiling.
- Camera / video capture drivers: a single high-resolution frame buffer often exceeds the kmalloc ceiling entirely, which is exactly why such drivers reach for CMA instead.
- Filesystem metadata caches: typically allocate many small objects rather than one giant block, so kmalloc’s ceiling is rarely a concern.
- Firmware loading: firmware images of a few hundred KB to a couple of MB usually fit; very large firmware blobs may need
vmalloc().
Common Mistakes and Troubleshooting
- Assuming kmalloc() always succeeds: always check the return value against
NULL, even for sizes well under the ceiling — the allocator can still fail under memory pressure. - Requesting a huge buffer “just to be safe”: over-sized allocation requests fail unpredictably as the system fragments over time, even if they succeeded right after boot.
- Not realizing kzalloc() has the same ceiling: since
kzalloc()is a thin wrapper overkmalloc(), it is bound by exactly the sameKMALLOC_MAX_SIZE. - Forgetting GFP flag context: a request within the ceiling can still fail immediately under
GFP_ATOMICin interrupt context if no suitably sized block is free at that instant, since atomic context cannot wait for reclaim.
Best Practices
- Keep individual
kmalloc()requests well under a page where possible; the slab allocator is most efficient at small, predictable sizes. - For anything approaching a few hundred KB or more, default to
kvmalloc()unless you specifically need DMA-capable, physically contiguous memory. - For large DMA buffers, plan for CMA or a dedicated reserved-memory region rather than fighting the kmalloc ceiling.
- Always check the return value, and always free with the matching function (
kfree()for kmalloc/kzalloc,kvfree()for kvmalloc/kvzalloc).
Performance and Security Considerations
Performance: requests that land inside an existing kmalloc-N slab cache are extremely fast, since the allocator just pops a free object off a per-CPU list. Requests that spill over into direct page-allocator territory (large kmalloc requests) are noticeably slower and more likely to fail as the system fragments.
Security: because kmalloc-backed allocations are physically contiguous and often DMA-visible, always validate any size value that originates from user space before passing it into an allocation call — an unchecked size can be used to probe allocator behavior or trigger unexpected failures deep in driver code.
Summary / Key Takeaways
The limit is PAGE_SIZE combined with MAX_ORDER, precomputed as KMALLOC_MAX_SIZE
On typical 4K-page x86_64/ARM64 systems the practical ceiling is a few megabytes
MAX_ORDER’s exact semantics changed in kernel 6.8, but the real-world ceiling is stable
Use vmalloc/kvmalloc or CMA once you approach or exceed the ceiling
Conclusion
Understanding the kmalloc() size ceiling is one of those small pieces of knowledge that saves hours of confused debugging once you write real drivers. As part of this free Linux kernel development course and free embedded systems course, remember the core idea: the limit exists because of a promise — physical contiguity — not because of an arbitrary restriction. In Part 2 of this lecture, we put this theory to the test with an original kernel module that empirically discovers the exact ceiling on your own running system.
FAQ
Q1. What is the maximum size I can request with kmalloc() on a typical Linux system?
On a standard x86_64 or ARM64 system with 4 KB pages, the practical ceiling is a few megabytes, determined by KMALLOC_MAX_SIZE.
Q2. Does kzalloc() have a different, smaller limit than kmalloc()?
No — kzalloc() is a wrapper around kmalloc() and shares exactly the same KMALLOC_MAX_SIZE ceiling.
Q3. What changed with MAX_ORDER in kernel 6.8?
The macro’s meaning was cleaned up so it now directly represents the largest usable page order, instead of being one greater than that order as in older kernels.
Q4. Why can’t the kernel just raise the kmalloc limit?
Because finding large runs of physically contiguous free pages gets exponentially harder as a system runs and fragments, regardless of how much total free RAM exists.
Q5. What should I use instead once I hit the ceiling?
vmalloc() or kvmalloc() for buffers that don’t need physical contiguity, or CMA-based allocation for large DMA-capable buffers.
Q6. Is the 4 MB figure fixed across all architectures?
No — it depends on that architecture’s PAGE_SIZE and MAX_ORDER. Some ARM64 configurations with larger page sizes end up with a different effective ceiling.
Q7. Will a request just under the ceiling always succeed?
Not necessarily. Being under KMALLOC_MAX_SIZE only means the request is theoretically allowed; the allocator still needs an actual free contiguous block that large at that moment.
Q8. Does GFP_ATOMIC change the size ceiling?
No, the size ceiling is the same regardless of GFP flags — but GFP_ATOMIC allocations are more likely to fail even for smaller sizes since they cannot wait for reclaim.