The Design and Implementation of the Anykernel and Rump Kernels

234
behavior is required by the active close of the TCP state machine. Having 10k
connections waiting forced us to wait for the timeout between running the tests for
the host kernel networking stack. In contrast, we could kill the process hosting the
rump kernel networking stack and start out with a new IP and a clean state in a
fraction of a second. While using the host TCP/IP stack was 0.03 times faster than
using a TCP/IP stack in the rump kernel, executing the benchmarks on the host
stack took over 10 times as long in wall time.
4.7 Summary
We evaluated the anykernel architecture and rump kernels in numerous different
ways, both with synthetic benchmarks and analyzing real world data from NetBSD
collected between 2007 and 2011.
We found that maintaining the anykernel architecture and rump kernel support
in the codebase adds minor maintenance effort. We found that less than 0.2% of
repository commits to the kernel source tree caused rump kernel build problems. We
added a special rumptest build command, which exploits the rump kernel symbol
closure to test linking. The command made it 30 times faster to buildtest rump
kernel support.
The use of rump kernels as an application library was evaluated with file system related
applications and was found to be a working approach. The makefs application
for NetBSD was reimplemented as a local rump kernel client, and the new version
was implemented in under 1/17th of the time taken for the original. This speedup
was due to the fact that the existing kernel file system driver could be used directly.
The new version also supports four additional file systems because driver support is
available without further effort.