Developing Kernel Drivers for Specific-Purpose Memory: Inside mempool_t

Every kmalloc() call is a promise the kernel might not keep. Under memory pressure, GFP_ATOMIC allocations skip reclaim entirely — no writeback, no swap, no waiting — because they’re called from contexts that can’t block: interrupt handlers, softirqs, anywhere holding a spinlock. When the free-page watermarks are low, that promise breaks, and kmalloc(GFP_ATOMIC) returns NULL. A driver that only has one allocation strategy now has a bug.

GFP_KERNEL doesn’t fix this either. It’s allowed to block, but blocking means entering reclaim — which can mean writing dirty pages back to the very block device whose completion handler you’re sitting in. That’s not a performance problem, it’s a deadlock: the I/O that would free memory is waiting on memory that only I/O completion can free.