Extensibility, Safety and Performance in the SPIN Operating System Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, Marc E. Fiuczynski, David Becker, Craig Chambers, Susan Eggers Department of Computer Science and Engineering University of Washington 1

SPIN OS Motivation: general purpose, UNIX-based operating systems can perform poorly when the applications have resource usage patterns poorly handled by kernel code Objective: a general purpose OS capable of handling specialized needs as well, with better performance and no security threats 2

MONOLITHICMICROKERNEL OS STRUCTURE 3

OS STRUCTURE-EXTENSIBLE 4

SPIN IDEA Using language and runtime services to provide low- cost, fine-grained, protected access to system resources Four design techniques – Enforced modularity: through use of Modula-3, which enforces interface boundaries between modules – Co-location: extensions live in kernel space – Logical Protection Domains: namespaces inside kernel, intradomain communication possible at cost of procedure call – Dynamic call binding: system events are dispatched to extensions 5

SPIN GOALS Extensibility – applications must be able to extend kernel functionality Safety – access to system resources must be controlled at the same granularity at which extensions are defined Performance – Requires low-overhead in the extension mechanisms – Application performance is the end goal 6

SPIN STRUCTURE 7

EXTENSIBILITY 8

EXTENSION MODEL Property of Extension – Easy to apply – Transparent – Efficient Extensions defined in terms of Event and Handler Provide controlled communication between Extension and Base system 9

Event raised Dispatcher call guards and handlers Evaluating guards If guard true then call handler EXTENSION MODEL 10

SAFETY 11

LANGUAGE-LEVEL PROTECTION Modula-3: relevant features that make extensions provided by applications safe to run in kernel space – Pointers cannot be forged: therefore an extension can only access the symbols exported through the public interfaces of any module (i.e. SpinPublic) – Pointers can only be de-referenced in a type-safe way (this check is also ensured across procedure calls between different domains) – Protection Domains (vs traditional VM approaches); Create, Resolve (dynamic linking), Combine (multiple domains) 12

13 SPIN Protection Model Goal: control the set of operations that can be applied to resources Capability-based protection system Protection domains

14 Capabilities Definition: A secure reference to a resource All kernel resources are referenced by capabilities Implementation: a type safe pointer to an abstract data type Extensions reference resources for which they have valid access A Pointer can be passed from the kernel to user-level applications as externalized references Key point: Capabilities refer directly to the underlying resources which they name

15 Protection Domains Define set of names that can be referenced by code with access to domain Domains is used to control dynamic linking, and corresponds to one or more safe object files Operations – Create: create a new domain – Resolve: dynamic linking – Combine: create a new aggregate domain

CORE SERVICES 16

MEMORY MANAGEMENT three components: – physical address service manages allocation of physical pages – virtual address service manages capabilities for virtual addresses – translation service manages relationship between physical and virtual addresses Extensions use the events raised by these three modules to create their own memory management schemes 17

THREAD MANAGEMENT SPIN doesn’t define thread model, instead defines structure upon which different threading models can be implemented. This structure is defined by a set of events coordinating processor allocation between schedulers and thread packages SPIN provides Strands An application-specific thread package defines an implementation of the Strand interface for its own threads. 18

PERFORMANCE 19

PLATFORM SPIN runs on DEC Alpha platforms Measurements – DEC Alpha 133Mhz AXP 3000/400 workstations Comparison systems – DEC OSF/1 V2.1 (monolithic operating system) – Mach 3.0 (microkernel) 20

MICROBENCHMARK-PROTECTED COMMUNICATION SPIN performed better for both system calls and cross-address calls. It’s in-kernel calls were significantly faster then either two of the other methods 21

MICROBENCHMARK-THREAD Thread performance in SPIN was better then that of OSF/1 and Mach in the ping-pong and fork-join tests. 22

MICROBENCHMARK-VIRTUAL MEMORY SPIN uses kernel extensions to define application-specific system calls for VM management. The multiple application-kernel interactions are reflected to the application by fast in- kernel modules, avoiding the need to use traps or messages. 23

MICROBENCHMARK-VIRTUAL MEMORY 24

NETWORK LATENCY & BANDWIDTH SPIN shows better network latency and bandwidth performance characteristics then OSF/1. SPIN, the application code executes in the kernel, where it has low-latency access to both the device and data. 25

END-TO-END PERFORMANCE SPIN utilizes half of the hardware as compared to OSF/1 for the same client load. SPIN tries to avoid double buffering between OS and application. 26

SPIN ADVANTAGES Extensions provide specialized service – Don’t execute unnecessary code Extensions close to kernel services – Low latency response to faults/interrupts – Invoking services is cheap 27

CONCLUSION SPIN demonstrates that it is possible to achieve good performance in an extensible system without compromising safety using a programming language with appropriate features and software architecture principles. 28

REFERENCES Extensibility, Safety and Performance in the SPIN Operating System Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, David Becker, Marc Fiuczynski, Craig Chambers, Susan Eggers Dynamic Binding for an Extensible System, Przemyslaw Pardyak and Brian Bershad SPIN Operating System web site: Documentation and source code qstream.org/~krasic/cs /summaries/paper17/SpinOS.ppt 29