Master the fundamental concepts of memory management through this focused micro-challenge.
The buddy allocator splits and merges power-of-two blocks of physical memory. Linux's page_alloc.c uses it for page-sized (and larger) allocations because coalescing is O(log n) with simple bitwise buddy math.
Allocation of 200 KB from a 1024 KB arena:
256 KB (next power of two)1024 into two 512 blocks, then split one 512 into two 256buddy = addr XOR sizecLoading…
Linux's physical page allocator in mm/page_alloc.c is a buddy system just like this one, tracking per-order free lists and coalescing blocks via the same base-address XOR trick to fight external fragmentation. Get the splitting or coalescing logic wrong and you reproduce the exact class of bug kernel developers chase when large contiguous allocations mysteriously fail under memory pressure.
Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.
Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.
You will implement free lists per order, split on alloc, and merge on free. This exercise asks you to print the tree after each operation so fragmentation behavior is visible.
Implement buddy system allocator for physical memory.
Requirements:
Three hints are available for this task, revealed one at a time inside the code workspace so you can struggle productively before seeing them.
All starter code and reference implementations are available for your local setup.
View on Github