The Design and Implementation of the Anykernel and Rump Kernels

91
is bound to a certain rump kernel virtual CPU simply has migration disabled. This
way, the scheduler will always try to acquire the same CPU for the thread.
Scheduler Priorities
The assumption is that a rump kernel is configured with a number of virtual CPUs
which is equal or greater to the number of frequently executing threads. Despite
this configuration, a rump kernel may run into a situation where there will be
competition for virtual CPUs. There are two ways to approach the issue of deciding
in which order threads should be given a rump CPU context: build priority support
into the rump CPU scheduler or rely on host thread priorities.
To examine the merits of having priority support in the rump CPU scheduler, we
consider the following scenario. Thread A has higher priority than thread B in the
rump kernel. Both are waiting for the same rump kernel virtual CPU. Even if the
rump CPU scheduler denies thread B entry because the higher priority thread A
is waiting for access, there is no guarantee that the host schedules thread A before
thread B could theoretically run to completion in the rump kernel. By this logic,
it is better to let host priorities dictate, and hand out rump kernel CPUs on a
first-come-first-serve basis. Therefore, we do not support thread priorities in the
rump CPU scheduler. It is the client’s task to call pthread_setschedparam() or
equivalent if it wants to set a thread’s priority.
3.3.2 Interrupts and Soft Interrupts
As mentioned in Section 2.3.3, a rump kernel CPU cannot be preempted. The mechanism
of how an interrupt gets delivered requires preemption, so we must examine
that we meet the requirements of both hardware interrupts and soft interrupts.