A Caching Model of Operating System Kernel Functionality

David R. Cheriton and Kenneth Duda

One-line summary: Scheduler activations part II, the micro-kernel.

Overview/Main Points

   * Concepts:

        o Micro-kernel OS's should provide modularity, reliability, and
          security over monolithic kernels. Some have turned out to be
          slower, larger, and more error-prone, and do not support
          domain-specific resource allocation policies any better. (due to
          VM system, exception handling, hardware, etc)

        o Cache Kernel caches OS system objects such as threads, address
          spaces, and application kernels. The higher level application
          kernels provide the management functions for the application,
          managing thread priority and address spaces and reducing
          supervisor-level complexity. Libraries are available for resource
          management (memory, processing, and communication), so that the
          application writer can customize selectively.

        o When a thread faults, it s loaded into the cache kernel address
          space, from which it jumps to the application-kernel address
          space, where the fault is handled.

        o Memory-based messaging used to communicate between address spaces,
          as well as to access devices controlled by the cache kernel (ie
          ethernet). Applications interested in receiving messages spawn a
          "signal thread" and register it with the service. Minimal copying
          and protection boundary crossing. An example is given for
          accessing devices directly from the application kernel, but I am
          not convinced that this is good/safe.

        o Cache Kernel handles resource allocation, application kernel
          mappings, and monitoring through the system resource manager,
          which is the first application kernel (loaded on boot-up). SRM
          serves as the owner for the other app kernel object, handling
          their write-back and granting requests for processing capacity,
          memory pages, and network capacity. Each application kernel
          handles its own resource mappings.

        o Complex relationships can occur between thread, address space, and
          message objects, requiring complex replacement mechanisms.

        o Code size is small in comparison to a monolithic kernel. Trap
          handling, signal delivery, and page fault handling compare
          favorably to Mach 2.5 and monolithic kernels.

Conclusions

The trend towards application-specific customizability is a good thing. This
paper offers another variation on this theme, offering the capability to
switch between/cache application kernels, threads, and address spaces.

The authors criticize micro-kernel OSs and point out the language dependence
of SPIN and Aegis, but leave out performance comparisons to justify their
statements. It would seem that they would suffer from the same problems with
hardware support (They criticize microkernels for their hardware support,
but then state that they only I/O that they support is high-speed
networking!?). I also do not buy that their support for different policies
is much different from features such as micro-kernel user-level virtual
memory support.
  ------------------------------------------------------------------------
Back to index