Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating...
-
Upload
alexina-daniels -
Category
Documents
-
view
215 -
download
0
Transcript of Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating...
![Page 1: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/1.jpg)
Extensibility, Safety and Performance in theSPIN Operating System
Ashwini KulkarniOperating SystemsWinter 2006
![Page 2: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/2.jpg)
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
![Page 3: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/3.jpg)
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
![Page 4: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/4.jpg)
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
![Page 5: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/5.jpg)
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
![Page 6: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/6.jpg)
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.
![Page 7: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/7.jpg)
Motivation, Goals & Approach
Generic Operating System
Module AModule B
Module C
Application Specific Extensible modules
Safety Performance
Extensibility
![Page 8: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/8.jpg)
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
![Page 9: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/9.jpg)
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
![Page 10: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/10.jpg)
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
![Page 11: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/11.jpg)
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.
![Page 12: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/12.jpg)
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
![Page 13: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/13.jpg)
SPIN Safety - Protection Domains
![Page 14: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/14.jpg)
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.
![Page 15: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/15.jpg)
SPIN – Extensibility Model
REF: Flexible Event Handling for an Extensible Operating System, Przemyslaw Pardyak, OSDI 94, November 1994
![Page 16: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/16.jpg)
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
![Page 17: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/17.jpg)
SPIN - Core Services
SPIN Memory Management Unit / Interface
![Page 18: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/18.jpg)
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
![Page 19: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/19.jpg)
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
![Page 20: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/20.jpg)
SPIN - Core Services
SPIN Thread Management Interface
![Page 21: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/21.jpg)
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.
![Page 22: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/22.jpg)
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
![Page 23: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/23.jpg)
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.
![Page 24: Extensibility, Safety and Performance in the SPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006.](https://reader030.fdocuments.net/reader030/viewer/2022032708/56649e6f5503460f94b6cc57/html5/thumbnails/24.jpg)
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