* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download ppt - Computer Science
Survey
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
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