Upload
belinda-ray
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Extensibility, Safety and Performance in the SPIN Operating System
Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer,
David Becker, Marc Fiuczynski, Craig Chambers, Susan Eggers
Presented By
Ninad Palsule
Motivation
General purpose OS Specialized OS Application needs a
resource control– Ex. DBMS
Hard: Support specialization in general purpose OS
Kernel
User
DBMS
Data page buffer Log page
12
Storage
Why it is hard?
Ref: Fig from presentation prepared by Author from http://www-spin.cs.washington.edu/
SPIN
Design Goals– Extensibility
Incremental changes
– Safety Correctness
– Good performance Efficiency
SPIN
Approach– Language and compiler support– Runtime facility
Techniques– Co-location
Requires dynamic linking Provides low cost communication
– Enforced modularity Modula – 3 Compiler enforce interface between modules Can’t access memory or execute privileged instruction unless access given through interface Modularity enforced by the compiler enables modules
– Logical protection domains Dynamic linker resolve code in different logical protection domain
– Dynamic call binding System Events
Extensibility
Extension model
Property of Extension– Easy to apply– Transparent– Efficient
Dynamically linked to Kernel address space Provide controlled communication between
Extension and Base system Extensions defined in terms of Event and Handler
Extension model
Event raised Dispatcher call guards and
handlers Evaluating guards If guard true then call
handler Safety issues
– Type checking Access Control Denial of service
– Runaway handlers– Too many handlers
Ref: Fig from paper 2 in Reference
Example: System call
Ref: From presentation prepared by Author of paper 2.
Programmer’s view
Ref: From presentation prepared by Author of paper 2.
SPIN structure
Ref: Fig from presentation prepared by Author from http://www-spin.cs.washington.edu/
Application: Video system components
Ref: Fig from Author presentation from http://www-spin.cs.washington.edu/
Safety
Modula – 3 support for SPIN
Type Safety– Array index checks (static & dynamic)– Pointer-safe casting
“VIEW” used to safe cast – Size of input should match with typed structure– Alignment should match
Isolation of untrusted code– Terminating untrusted code
“EPHEMERAL” procedure tag for killable procedures– Isolating errors in untrusted code
Implicit exception for unhandled exception Enforce modularity
– Interface, Modules and procedures Automatic storage management
Protection model
Control set of operations on resource Conventional OS uses Address space as a
protection model SPIN
– Capabilities– Protection domain
Capabilities
Implemented using pointers Pointer is a reference to block of memory whose
type is declared within interface. Externalized Reference before sending to user
space Unforgeable reference to resources (system object
and interfaces) Extension reference resources for which they have
valid access Interfaces protected to allow different extensions to
have different views on services
Protection domains
Set of accessible names available for execution context
Naming and protection interface at level of language– Name ‘c’ is a instance of type ‘Console.T’
Domains can be intersecting or disjoint
Domain interface
Export/Import domain at run-time
Fig from paper [2]
Core Services
Core Services
Manages Memory and Processor resources Export interfaces for Extensions Extensible Memory management
– Three components: Physical storage, Naming(virtual address) and Translation
Extensible thread management– Strands – No state, share processor– Application provide its own thread package– Scheduler runs in Kernel– Checkpoint and Resume events– Block / Unblock Events
Performance
Methodology
Comparative study– SPIN V0.4– DEC OSF/1 V2.1 (Monolithic OS)– Mach 3.0 (Micro-kernel)
Hardware– DEC Alpha 133 MHz AXP 3000/400 workstation, 64 MB
RAM, 512 KB unified external cache
Tests– Micro benchmarks– End-to-end performance– Networking
Micro benchmark – Protected communication
NULL procedure call Protected in-kernel :
SPIN’s cross domain procedure call
Cross Address space call: SPIN’s extension
Protected communication overhead in microseconds
Micro benchmark: Thread Management overhead
Network Latency and Bandwidth
End-to-end performance
Conclusion
It is possible to achieve all three in single OS (Extensibility, Safety and Performance)
Extend easily with dynamic linking Use of language and compile with Event facility for
safety Communication cost is low Issues
– Dispatcher performance?– Does it solve all Safety issues? How do we test
correctness?– Language restrictions, changes in Modula - 3
References
1. Extensibility, Safety and Performance in the SPIN Operating System Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, David Becker, Marc Fiuczynski, Craig Chambers, Susan Eggers
2. Dynamic Binding for an Extensible System, Przemyslaw Pardyak and Brian Bershad
3. Safe Dynamic Linking in an Extensible Operating System, Emin Sirer, Marc Fiucynski, Przemyslaw Pardyak, Brian Bershad
4. Language Support For Extensible Operating System, Wilson Hsieh, Marc Fiuczynski, Charles Garrett, Stefan Savage, David Becker, and Brian Bershad
5. SPIN Operating System web site: Documentation and source code http://www-spin.cs.washington.edu/