The Design and Implementation of the Anykernel and Rump Kernels

112
The kernel with uniprocessor locking performs 34% better than the multiprocessor
version on a uniprocessor rump kernel. This significant difference can be explained
by the fact that creating files on memory file systems (rump_sys_open(O_CREAT))
is very much involved with taking and releasing locks (such as file descriptor locks,
directory locks, file object locks ...) and very little involved with I/O or hypervisor
calls. To verify our results, we examined the number of mutex locks and
reader/writer locks and we found out they are taken 5,438,997 and 1,393,596 times,
respectively. This measurement implies the spinlock/release cycle fastpath in the
100ns range, which is what we would expect from a Core2 CPU on which the test
wasrun. TheMT4 case is slower than MT 2, because the test host has only two
physical cores, and four threads need to compete for the same physical cores.
The multiprocessor version where the number of threads and virtual CPUs matches
the host CPU allocation wins in wall time. However, if it is possible to distribute
work in single processor kernels on all host CPUs, they will win in total performance
due to IPC overhead being smaller than memory bus locking overhead [12].
3.6 Application Interfaces to the Rump Kernel
Application interfaces are used by clients to request services from the rump kernel.
Having the interfaces provided as part of the rump kernel framework has two purposes:
1) it provides a C level prototype for the client 2) it wraps execution around
the rump kernel entry and exit points, i.e. thread context management and rump
kernel virtual CPU scheduling.
The set of available interfaces depends on the type of the client. Since the rump
kernel provides a security model for remote clients, they are restricted to the system
call interface — the system call interface readily checks the appropriate permissions
of a caller. A local client and a microkernel server’s local client are free to call