Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006

Agenda Introduction Background – Goals and Approach – Motivation to design an extensible OS – Past researches SPIN System Architecture Core Services Provided in SPIN SPIN System Performance Gauge Conclusions

Introduction SPIN – University of Washington Dynamically reconfigurable operating system extensions to meet performance and functionality requirements of applications Match OS implementation & interface to meet application demand – Tune OS to meet application needs E.g. Multimedia applications like streaming video – provide demands that are poorly matched by generic operating systems

Introduction – Goals & Approach Build a general purpose operating system that provides extensibility, safety and good performance Relies on four techniques implemented at the level of the language or its run time. – Co-location – Enforced modularity – Logical protection domains – Dynamic call binding

System Overview SPIN OS consists of set of extension services & core system services – Execute within the Kernel address space Extensions can be loaded into kernel any time Once loaded, integrate themselves into existing infrastructure Provide application specific system services as desired

Motivation Balance generality and specialization – Most OS designed keeping in mind general purpose applications – Need to fine tune system level procedures and functions to better adjust to the needs of the application – Increase application specific system performance Most general systems can be modified (made extensible) to suit specific needs Need to keep system safety in mind. Incorporate solid protection mechanisms.

Motivation, Goals & Approach Generic Operating System Module A Module B Module C Application Specific Extensible modules SafetyPerformance Extensibility

Related work Previous research works demonstrated tensions between extensibility, safety and performance Hydra – allowed applications to manage resources through multi-level policies – System designed with large objects – Large programming effort for small extensions Use of micro-kernels – Exports small no of abstractions including threads, address space and communication channels – Application specific extensions occur at or above the kernel level interface – Needs large modifications even for small extensibility

Related Work “Little Languages” – – Expression of control and data structures cumbersome – Narrow interface between programming environment and rest of the system – Interpretation overhead can limit performance Many systems provide interface to insert arbitrary code into kernel at run-time – Affects system safety and fault tolerance Aegis – efficient trap redirection to export hardware services (exception handling, TLB management) directly to applications – Similar notion to SPIN but different approach SPIN relies on language services only for code extensions within the kernel. – Operating system and programs isolated via virtual address spaces

SPIN Architecture Provides a software infrastructure for safely combining system and application code. Achieved by following two models: Protection model – Capabilities – Protection Domains Extensibility Model

SPIN Safety - Capabilities All kernel resources referenced by capabilities What is a capability? – An unforgeable reference to a resource which can be a system object, an interface or a collection of interfaces – E.g. – a physical page, physical page allocation interface and the virtual memory system respectively Individual resources protected. Only extensions having access to resources can reference them. SPIN implements capabilities directly using pointers, supported by the language. – Compiler, at compile time, prevents a pointer from being forged or dereferenced in a way inconsistent with its type – No significant overhead for using pointers – Maintain a table of type safe references to the kernel level data structures. Grant access to pointer references based on this table.

SPIN Safety – Protection Domain Naming and Protections domains are at language level. Not at virtual memory system level Name space management occurs at language level Protection domains: set of names or program symbols, that can be referenced by code with access to that domain Domains can be intersecting or disjoint enabling applications to share services or define new ones – Domain interfaces (shown in the next slide) Create Resolve Combine

SPIN Safety - Protection Domains

SPIN - Architecture Extension model – Modularity – Event based system. Extensions defined in terms of events and handlers – Multiple handlers can be provided for every event Default handler Other handlers – Event dispatcher would arbitrate on which handler to invoke in response to a flagged event.

SPIN – Extensibility Model REF: Flexible Event Handling for an Extensible Operating System, Przemyslaw Pardyak, OSDI 94, November 1994 Przemyslaw Pardyak

Core Services Memory Management Three basic components of memory management  Physical address service : controls the use and allocation of physical pages.  Virtual address service: Allocates capabilities for virtual addresses  Translation service: Express the relationship between virtual addresses and physical memory Support services like demand-paging, copy-on- write, distributed shared memory, concurrent garbage collection Do not define an address space model directly

SPIN - Core Services SPIN Memory Management Unit / Interface

Core Services: Thread Management User-level threads require knowledge of kernel events Scheduler Activations have high communication overhead due to kernel crossings SPIN: An application can provide its own thread package and scheduler that executes within the kernel

Core Services - Thread Management SPIN defines structure for Implementation of thread model Strands similar to user-level threads, have no kernel context Scheduler multiplexes resources among Strands An Application Specific thread package defines an implementation of the strand Interface for its own threads The Interface : Two events Block, Unblock – raised by kernel to signal changes in strand’s execution state to application-specific Scheduler. Allows implementation of new scheduling policies Scheduler communicates with Thread Package using Checkpoint and Resume

SPIN - Core Services SPIN Thread Management Interface

SPIN – System Performance Gauge System performance based on following four parameters: – Size (extensible module code size) – Micro-benchmarks – Networking – Evaluate extensible modules for networking protocols – End – to – end application performance. SPIN System components: – Sys: extensibility machinery, naming, linking & dispatching – Core: virtual memory management, scheduling services – RT: automatic memory management & exception handling – Lib: standard data structures – lists, queues, hash tables etc – Sal: lower level device drivers and MMU Code Size review of the extensible system components shows that there is no significant effort overhead in making the system extensible using SPIN architecture.

SPIN – System Performance Micro benchmarks: – Overhead of basic system functions like procedure calls, thread management, virtual memory Comparison between DEC OSF/1, Mach and SPIN for “null procedure calls”, thread management & VMM – Reflects cost of only control transfer – Tables below show overhead in micro-seconds Null procedure call Thread Management Virtual Memory Management

SPIN – System Performance Networking – Extensible support for networking protocols Protocol stack that routes incoming network packets to application-specific endpoints within the kernel Ovals represent events raised to route the control to handlers (box representation) Handlers implement labeled protocol Results show increased performance in terms of reduced latency.

Conclusions Possible to achieve Extensible OS support without compromising on system safety Co-location, forced modularity, logical protection domains and dynamic binding allow extensions to be defined / installed dynamically