Why Linux Kernel Memory Allocation Is Not Like malloc()

In user space, malloc() can, in principle, hand you almost any number of bytes you ask for, because the C library’s heap manager is free to carve up virtual memory however it likes. The kernel cannot afford that luxury. It runs in a privileged, resource-constrained environment where fragmentation, locking overhead, and cache-line behaviour matter enormously, so kernel memory allocation is built around two cooperating layers instead of one general-purpose heap.

Every kernel memory allocation ultimately bottoms out at the page allocator, also called the buddy system, because physical RAM itself is managed in fixed-size pages (commonly 4 KB on most architectures). The slab layer sits on top of the page allocator purely as an optimisation: most kernel allocations are small and short-lived, so handing out whole pages for a 40-byte structure would be absurdly wasteful. The slab layer instead reserves a handful of pages up front and slices them into same-sized objects, which is where kmalloc() buckets come from.

How kmalloc() Memory Allocation Buckets Actually Work

When your driver calls kmalloc(size, GFP_KERNEL), the kernel does not allocate exactly size bytes. It rounds your request up to the nearest available bucket. On a typical 64-bit build you will find general-purpose buckets around these sizes:

Notice the pattern: waste is small right after you cross into a new bucket and grows steadily until you hit the next one, where it resets. This “sawtooth” behaviour is completely predictable once you understand it, and it is one of the most important things to internalise in this free linux kernel development course.

Where kmalloc() Hands Off to the Page Allocator

General-purpose kmalloc() buckets stop at a fixed ceiling — historically around 8 KB, though the exact cutoff depends on architecture and kernel configuration. Ask for anything larger and the slab layer cannot help you anymore; the request is served directly by the page allocator instead. This is the point where kernel memory allocation waste can get genuinely ugly, because the page allocator can only give you memory in power-of-two page counts.

The moment a request crosses just past a page-order boundary (for example, just over 2 MB when the buddy system’s next available block is 4 MB), the kernel must round all the way up to that next power-of-two block. The waste in that single allocation can approach 90% of the memory actually handed out. This is exactly the kind of allocation pattern that quietly bloats memory usage on embedded boards and low-RAM devices, and it is a favourite interview question for embedded Linux roles.

Measuring Real Allocation Size: ksize() and kmalloc_size_roundup()

You cannot manage what you do not measure. The kernel gives driver authors two complementary tools to find out how much memory an allocation truly consumes.

ksize() — Check After Allocation

ksize() reports the true usable size of a pointer that kmalloc() already returned. It has existed for a long time and is still useful for auditing, but modern kernels discourage using it to “opportunistically” grow into memory you did not originally ask for, since compiler-based buffer-overflow hardening (things like __alloc_size hints and FORTIFY_SOURCE) work best when the requested size and the used size agree from the start.

#include <linux/slab.h>

void *buf = kmalloc(100, GFP_KERNEL);
if (buf) {
    pr_info("requested=100 actual_usable=%zu\n", ksize(buf));
    kfree(buf);
}

kmalloc_size_roundup() — Check Before Allocation

Modern kernels added kmalloc_size_roundup() precisely to fix the awkwardness of discovering your real bucket size only after allocating. It answers “how many bytes would I actually get if I asked for N?” without allocating anything, which lets you size buffers correctly up front instead of relying on ksize() afterwards.

#include <linux/slab.h>

size_t want = 100;
size_t real_bucket = kmalloc_size_roundup(want);
pr_info("asking for %zu will actually give %zu\n", want, real_bucket);

void *buf = kmalloc(real_bucket, GFP_KERNEL);

Avoiding Page Allocator Waste with alloc_pages_exact()

When a driver genuinely needs more memory than the slab ceiling allows, and that memory does not need to be a clean power-of-two size, the page allocator’s default API is the wrong tool. The kernel instead provides alloc_pages_exact() and its counterpart free_pages_exact(), which internally allocate the necessary power-of-two block but then free back the unused tail pages, leaving you with memory sized much closer to what you actually asked for.

#include <linux/gfp.h>

size_t need = 2200100; /* just over 2 MB */
void *mem = alloc_pages_exact(need, GFP_KERNEL);
if (mem) {
    /* use mem ... */
    free_pages_exact(mem, need);
}

This does not eliminate rounding entirely — you still get memory in whole-page units — but it avoids the extreme power-of-two jumps that make naive large allocations so costly.

Real-World Use Case: Why This Matters on Embedded Boards

Picture a network driver on a 512 MB embedded board that allocates several receive buffers slightly larger than 2 MB each during initialisation, using plain kmalloc()-style page allocation without checking actual usage. On a desktop with 32 GB of RAM nobody would notice. On that embedded board, a handful of such allocations can eat tens of megabytes more than intended, indirectly triggering the OOM killer under memory pressure elsewhere in the system. This is precisely the class of bug this free linux device drivers course trains you to spot before it ships.

Common Mistakes and Troubleshooting Tips

Best Practices for Kernel Memory Allocation

• Know your bucket sizes before designing a data structure that gets allocated frequently.
• Prefer kmalloc_size_roundup() over after-the-fact ksize() queries in new code.
• For allocations that regularly cross the slab ceiling, evaluate alloc_pages_exact() or vmalloc() depending on whether physical contiguity is required.
• Use /proc/slabinfo and /proc/meminfo to sanity-check real-world memory pressure during driver bring-up.
• Batch small, frequent allocations into a dedicated kmem_cache instead of repeated generic kmalloc() calls where it makes sense.

Performance and Security Considerations

Beyond raw memory waste, bucket rounding interacts with security hardening. Because objects of the same bucket size share a cache, precise sizing reduces the “spray” surface that certain heap-exploitation techniques rely on, and it keeps compiler-assisted bounds checking (FORTIFY_SOURCE, KASAN, UBSAN) accurate. Getting allocation sizing right is therefore not just a memory-efficiency exercise — it is part of writing defensively secure kernel code, a theme you will see repeated throughout this free linux kernel development course.

Summary and Key Takeaways

• Kernel memory allocation happens in two layers: the slab allocator for small, fixed-size buckets, and the page allocator for whole pages.
• kmalloc() always rounds your request up to the nearest bucket, and waste follows a predictable sawtooth pattern.
• Crossing a page-order boundary can spike waste close to 90–100% for a single large allocation.
• kmalloc_size_roundup() is the modern way to know your real allocation size before you allocate, replacing many older ksize() patterns.
• alloc_pages_exact() / free_pages_exact() reduce waste for large allocations that don’t need to be power-of-two sized.

Conclusion

Kernel memory allocation looks simple from the outside — call kmalloc(), get a pointer back — but underneath it hides a bucket-and-page system with real, measurable waste built into its design. Understanding where that waste comes from, and reaching for tools like kmalloc_size_roundup() and alloc_pages_exact() when it matters, is exactly the kind of practical skill that separates driver code that merely works from driver code that is production-ready. Keep following this free linux kernel development course and free embedded systems course as we continue into the different slab allocator implementations in the next lecture.