A kernel memory leak made Redox builds five times slower
Victoria Shinder3 min readRedox OS - the Unix-like general-purpose microkernel written in Rust - published its August report on 31 August, written by Ribbon and Ron Williams, with an apology for the delay. It is worth reading a month late because two of the items are measurements rather than announcements.
The first is Redox Rings, a ring-buffer communication API built over several months by Ibuki Omatsu and Anhad Singh, with guidance from 4lDO2 and bug fixes from Wildan Mubarok. The project describes it as the equivalent of Linux's io_uring system call API, and it now backs the NVMe driver, RedoxFS and RAMFS. In a benchmark that bypasses the RedoxFS filesystem, comparing synchronous system calls against ring buffers for NVMe read and write, the improvement is 14-15x.
The second is a bug hunt. Wildan Mubarok spent months chasing a gradual degradation in GCC compilation performance and found a kernel memory leak: compiling the os-test suite under QEMU had crept from two hours to ten, with out-of-memory failures along the way. After the fix, the same compile takes about thirty minutes - faster than the two-hour figure the degradation started from.
The rest of the month: improved UEFI compatibility, which got an MSI Modern 14 C7M laptop booting; multi-core support for AArch64/ARM64 from lbecher, with the project saying plainly that more testing is needed before the performance effect is known; initial NUMA memory management from Aadarsh, including local-node allocation by default and a libredox API for allocation policy, so far exercised only under QEMU; and process priorities plus system priority tuning from Akshit Gaur, closing out the RSoC scheduler project, along with a final EEVDF write-up.
What it means
The leak is the more instructive of the two findings, because of how it presented. Nothing failed - a build simply got slower, month over month, until it was five times its original cost and started running out of memory. That is a shape that resists diagnosis: every individual run succeeds, the trend is only visible if somebody records build times over months, and the natural explanation for a compiler getting slower is the compiler or the code. It took months to attribute it to the kernel. The transferable lesson for anyone maintaining a system is that a slow drift in a number nobody owns is the hardest class of defect to see, and the fix here produced a build faster than the oldest baseline - meaning the leak had been present, and quietly taxing, for longer than the degradation was noticed.
The Rings number deserves a caveat the project itself supplies: the 14-15x figure is measured with RedoxFS bypassed, so it is a statement about the syscall and driver path, not about what a filesystem workload will see. Compare it with the ARM64 entry, where the report declines to claim any improvement until testing is done. A monthly report that distinguishes between "measured under these conditions", "implemented, effect unknown" and "tested only in QEMU, real hardware welcome" is doing something more useful than a changelog, and it is the reason this one is worth a read four weeks after it went up.