Extensibility Safety and Performance in the SPIN Operating

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 Presented by: SUBASIS SAMAL

OUTLINE • • Introduction Motivation Goals and approach Related works Spin Architecture Core services System performance

Introduction • Spin is an OS that can be dynamically specialized to safely meet the performance and functionality requirements of the application. • Spin provides an extension mechanism, together with a core set of extensible services that allow application to safely change the OS interface and implementation.

Motivation

Motivation • Spin is motivated by the need to support applications that present demands poorly matched by an OS implementation or interface. • Most general systems can be specialized to address the performance and functional requirements of a particular application’s needs.

Goals and Approach • Build a general purpose OS that provides extensibility, safety and good performance. • Use of language and runtime services to provide low-cost, finegrained, protected access to system resources. • Spin OS relies on four techniques: – Enforced modularity: Extensions are written in 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: Extensions execute in response to system events.

Related work • Hydra [Wulf et al ’ 81] • Microkernels [Bershad et al ‘ 90] • Cross-Domain Communication [Hamilton & Kourgiouris ’ 93] • Code install in kernel at runtime [Heidemann & Popek ’ 94] • Software Fault Isolation [Wahbe et al ’ 93] • Aegis [Engler et al ’ 95]

SPIN STRUCTURE 8

Spin architecture Spin and its extensions are written in Modula-3. Key features include support for interfaces, type safety, automatic storage management, threads, exceptions Based on two models: • Protection model • Extension model

Protection model • Controls set of operations that can be applied to resources. • Capabilities : Unforgeable reference to a resource. - All kernel resources are referenced by capabilities. - Resources are protected to ensure that extension reference the resources to which they have been given access. - SPIN implements capabilities directly using pointers. - A Pointer can be passed from the kernel to user-level applications as externalized references.

Cont. . • Protection domain - Defines a set of names, or program symbols, that can be referenced by code with access to the domain. - A domain, named by a capability, 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

Extension model • Controlled communication facility between extensions and the base system. • Extensions in SPIN are defined in terms of events and handlers. • The primary right to handle an event is restricted to the default implementation module for the event, which is the module that statically exports the procedure named by the event. • Other modules may request that the dispatcher install additional handlers or even remove the primary handler. Dispatcher contacts primary implementation module. If denied installation fails. • If allowed, the implementation module can provide a guard to be associated with the handler.

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

Core services • SPIN provides a set of core services that manage memory and processor resources. • The core services provided by SPIN are: - Extensible memory management - Extensible thread management

Extensible memory management • A memory management system is responsible for the allocation of virtual addresses, physical addresses, and mappings between the two. • Three components: – Physical address service controls use and allocation of physical pages – Virtual address service allocates capabilities for virtual addresses – Translation service expresses relationship between physical and virtual addresses

Extensible thread management • Application can provide its own thread package and scheduler that executes within the kernel. • SPIN doesn’t define thread model, instead defines structure upon which different threading models can be implemented. • Spin use strands. • Operations: - Block - Unblock - Checkpoint - Resume

System performance • SPIN runs on DEC Alpha platforms • Measurements – DEC Alpha 133 Mhz AXP 3000/400 workstations • Comparison systems – DEC OSF/1 V 2. 1 (monolithic operating system) – Mach 3. 0 (microkernel)

Microbenchmarks : They reveal the overhead of basic system functions, such a protected procedure call, thread management, and virtual memory and define the bounds of system performance and provide a framework for understanding larger operations. - Protected communication For both system calls and cross-address calls SPIN performed better It’s in-kernel calls were significantly faster then either two of the other methods

Thread management Thread performance in SPIN was better than that of OSF/1 and Mach in the ping-pong and fork-join tests.

Virtual memory SPIN outperforms the other systems on the virtual memory benchmarks for two reasons: • SPIN uses kernel extensions to define application-specific system calls for virtual memory management. • Each virtual memory event, which requires a series of interactions between the kernel and the application, is reflected to the application through a fast in-kernel protected procedure call.

A protocol graph in SPIN

Network latency and bandwidth Spin outperforms the DEC OSF/1 with respect to latency and bandwidth performance. • For SPIN, the application code executes as an extension in the kernel, where it has low-latency access to both the device and data. •

End-to-end performance • SPIN utilizes half of the hardware as compared to OSF/1 for the same client load. • SPIN allows a server to control its cache and avoid double buffering between OS and application

Conclusion • Spin OS demonstrates that it is possible to achieve good performance in an extensible system without compromising safety. • Enables an efficient way to extend services along with basic set of core services. • Programming languages with appropriate features support can be used to construct future operating systems

THANK YOU