The Design and Implementation of the Anykernel and Rump Kernels

99
implementations for these allocators from the standard NetBSD kernel and provide
them as part of the rump kernel base.
An exception is the 4.3BSD/4.4BSD malloc() [73]; we stress that in this section
malloc refers to the in-kernel implementation of the allocator. In contrast to the
dynamic nature of the abovementioned allocators, the malloc implementation uses
a single contiguous memory range for all allocations (kmem_map). The size of this
range is calculated from total system memory and the range is allocated at system
bootstrap time. In a rump kernel this behavior is not desirable, since it sets static
limits for the system. Due to this reason we did not extract malloc and instead
reimplemented the interface by relegating requests to the hypercall layer. Since
malloc is being retired in NetBSD in favor of the newer style allocators, we did not
see it necessary to spend effort on being able to extract the implementation instead
of using the hypervisor’s memory allocator directly. Notably, the situation with
malloc may need to be revisited if rump kernels are to be ported to a host which
does not provide a general purpose memory allocator in itself and malloc is not fully
retired by then.
3.4.3 Pagedaemon
The NetBSD kernel uses idle memory for caching data. As long as free memory is
available, it will be used for caching. The pagedaemon serves the purpose of pushing
out unnecessary data to recycle pages when memory is scarce. A mechanism is
required to keep long-running rump kernels from consuming all memory available
from the host for caching. The choices are to either eliminate caching and free
memory immediately after it has been used, or to create a pagedaemon which can
operate despite memory access information not being available with the help of a
MMU. Since eliminating caching is undesirable for performance reasons, we chose
the latter option.