Download ppt - Computer Science

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Berkeley Software Distribution wikipedia , lookup

Library (computing) wikipedia , lookup

Process management (computing) wikipedia , lookup

Copland (operating system) wikipedia , lookup

Distributed operating system wikipedia , lookup

Security-focused operating system wikipedia , lookup

DNIX wikipedia , lookup

Spring (operating system) wikipedia , lookup

Kernel (operating system) wikipedia , lookup

Transcript
Extensibility, Safety and Performance
in
the SPIN Operating System
Brian Bershad, Stefan Savage, Przemyslaw Pardyak,
Emin Gun Sirer, Marc E. Fiuczynski, David Becker,
Craig Chambers, Susan Eggers
Department of Computer Science and Engineering
University of Washington
1
SPIN OS
• Motivation: general purpose, UNIX-based
operating systems can perform poorly when
the applications have resource usage patterns
poorly handled by kernel code
• Objective: a general purpose OS capable of
handling specialized needs as well, with better
performance and no security threats
2
OS STRUCTURE
MONOLITHIC
MICROKERNEL
3
OS STRUCTURE-EXTENSIBLE
4
SPIN IDEA
• Using language and runtime services to provide lowcost, fine-grained, protected access to system
resources
• Four design techniques
– Enforced modularity: through use of Modula-3, which
enforces interface boundaries between modules
– Co-location: extensions live in kernel space
– Logical Protection Domains: namespaces inside kernel,
intradomain communication possible at cost of procedure
call
– Dynamic call binding: system events are dispatched to
extensions
5
SPIN GOALS
• Extensibility
– applications must be able to extend kernel
functionality
• Safety
– access to system resources must be controlled at the
same granularity at which extensions are defined
• Performance
– Requires low-overhead in the extension mechanisms
– Application performance is the end goal
6
SPIN STRUCTURE
7
EXTENSIBILITY
8
EXTENSION MODEL
• Property of Extension
– Easy to apply
– Transparent
– Efficient
• Extensions defined in terms of Event and Handler
• Provide controlled communication between
Extension and Base system
9
EXTENSION MODEL
•
•
•
•
10
Event raised
Dispatcher call guards and handlers
Evaluating guards
If guard true then call handler
SAFETY
11
LANGUAGE-LEVEL PROTECTION
• Modula-3: relevant features that make
extensions provided by applications safe to run in
kernel space
– Pointers cannot be forged: therefore an extension can
only access the symbols exported through the public
interfaces of any module (i.e. SpinPublic)
– Pointers can only be de-referenced in a type-safe
way (this check is also ensured across procedure calls
between different domains)
– Protection Domains (vs traditional VM approaches);
Create, Resolve (dynamic linking), Combine (multiple
domains)
12
SPIN Protection Model
• Goal: control the set of operations that can be
applied to resources
• Capability-based protection system
• Protection domains
13
Capabilities
• Definition: A secure reference to a resource
• All kernel resources are referenced by capabilities
• Implementation: a type safe pointer to an abstract
data type
• Extensions reference resources for which they have
valid access
• A Pointer can be passed from the kernel to user-level
applications as externalized references
• Key point: Capabilities refer directly to the underlying
resources which they name
14
Protection Domains
• Define set of names that can be referenced by code
with access to domain
• Domains is used to control dynamic linking, and
corresponds to one or more safe object files
• Operations
– Create: create a new domain
– Resolve: dynamic linking
– Combine: create a new aggregate domain
15
CORE SERVICES
16
MEMORY MANAGEMENT
• three components:
– physical address service manages allocation of
physical pages
– virtual address service manages capabilities for
virtual addresses
– translation service manages relationship between
physical and virtual addresses
• Extensions use the events raised by these three
modules to create their own memory
management schemes
17
THREAD MANAGEMENT
• SPIN doesn’t define thread model, instead
defines structure upon which different
threading models can be implemented.
• This structure is defined by a set of events
coordinating processor allocation between
schedulers and thread packages
• SPIN provides Strands
• An application-specific thread package defines
an implementation of the Strand interface for
its own threads.
18
PERFORMANCE
19
PLATFORM
• SPIN runs on DEC Alpha platforms
• Measurements
– DEC Alpha 133Mhz AXP 3000/400 workstations
• Comparison systems
– DEC OSF/1 V2.1 (monolithic operating system)
– Mach 3.0 (microkernel)
20
MICROBENCHMARK-PROTECTED
COMMUNICATION
• SPIN performed better for both system calls
and cross-address calls.
• It’s in-kernel calls were significantly faster then
either two of the other methods
21
MICROBENCHMARK-THREAD
• Thread performance in SPIN was better then
that of OSF/1 and Mach in the ping-pong and
fork-join tests.
22
MICROBENCHMARK-VIRTUAL
MEMORY
• SPIN uses kernel extensions to define
application-specific system calls for VM
management.
• The multiple application-kernel interactions
are reflected to the application by fast inkernel modules, avoiding the need to use
traps or messages.
23
MICROBENCHMARK-VIRTUAL
MEMORY
24
NETWORK LATENCY & BANDWIDTH
• SPIN shows better network latency and
bandwidth performance characteristics then
OSF/1.
• SPIN, the application code executes in the
kernel, where it has low-latency access to
both the device and data.
25
END-TO-END PERFORMANCE
• SPIN utilizes half of the hardware as compared
to OSF/1 for the same client load.
• SPIN tries to avoid double buffering between
OS and application.
26
SPIN ADVANTAGES
• Extensions provide specialized service
– Don’t execute unnecessary code
• Extensions close to kernel services
– Low latency response to faults/interrupts
– Invoking services is cheap
27
CONCLUSION
SPIN demonstrates that it is possible to
achieve good performance in an extensible
system without compromising safety using a
programming language with appropriate
features and software architecture principles.
28
REFERENCES
•
•
•
•
•
•
•
•
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
Dynamic Binding for an Extensible System, Przemyslaw Pardyak and Brian
Bershad
SPIN Operating System web site: Documentation and source code
http://www-spin.cs.washington.edu/
http://www.cc.gatech.edu/classes/AY2003/cs6210_fall/papers/spin.pdf
http://www.cs.nyu.edu/courses/spring99/G22.3250-001/lectures/lect26.pdf
www.cs.pdx.edu/~walpole/class/cs533/spring2006/slides/132.ppt
www.cs.pdx.edu/~walpole/class/cs533/winter2007/slides/142.ppt
qstream.org/~krasic/cs508-2006/summaries/paper17/SpinOS.ppt
29