Download ppt

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
Extensibility
Generic Operating System
Module A
Module C
Module B
Application Specific
Extensible modules
Safety
Performance
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
–
Affects system safety and fault tolerance
–
Similar notion to SPIN but different approach
–
Operating system and programs isolated via virtual
address spaces
–
–



Many systems provide interface to insert
arbitrary code into kernel at run-time
Aegis – efficient trap redirection to export
hardware services (exception handling, TLB
management) directly to applications
SPIN relies on language services only for code
extensions within the kernel.
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-onwrite, 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:
–
–
–
–

SPIN System components:
–
–
–
–
–

Size (extensible module code size)
Micro-benchmarks
Networking – Evaluate extensible modules for networking
protocols
End – to – end application performance.
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
Virtual Memory Management
Thread 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