Extensibility, Safety and Performance in theSPIN Operating System

Ashwini KulkarniOperating SystemsWinter 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 AModule B

Module C

Application Specific Extensible modules

Safety Performance

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

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