Upload
mercia
View
39
Download
4
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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