1 / 21

EXTENSIBILITY, SAFETY AND PERFORMANCE IN THE SPIN OPERATING SYSTEM

EXTENSIBILITY, SAFETY AND PERFORMANCE IN THE SPIN OPERATING SYSTEM. Brian N. Bershad, Stefan Savage, Przemysław Pardyak, Emin G¨un Sirer, Marc E. Fiuczynski, David Becker, Craig Chambers, Susan Eggers Presenter: Myeonwoo Lim. OUTLINE. Overview Motivation SPIN Architecture Core Services

waite
Download Presentation

EXTENSIBILITY, SAFETY AND PERFORMANCE IN THE SPIN OPERATING SYSTEM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EXTENSIBILITY, SAFETY AND PERFORMANCE IN THE SPIN OPERATING SYSTEM Brian N. Bershad, Stefan Savage, Przemysław Pardyak, Emin G¨un Sirer, Marc E. Fiuczynski, David Becker, Craig Chambers, Susan Eggers Presenter: Myeonwoo Lim

  2. OUTLINE • Overview • Motivation • SPIN Architecture • Core Services • Performance • Conclusions

  3. OVERVIEW • What is spin? • SPIN is a dynamically extensible operating system that allows user applications to safely change the operating system's interface and implementation. Extensions are linked into the operating system kernel at application runtime, enabling them to access system services with low overhead.

  4. OVERVIEW • Goals SPIN combines research in systems, languages, and compilers to achieve the three fundamental goals of modern operating systems. • 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

  5. OVERVIEW • Approach for the goals • Co-location • Extensions live in kernel space • Enforced modularity • Extensions are written in Modula-3, which enforces interface boundaries between modules. • Logical protection domains • Namespaces inside kernel, intra-domain communication possible at cost of procedure call • Dynamic call binding • Extensions execute in response to system events.

  6. MOTIVATION • SPIN is motivated by the need to support applications that present demands poorly matched by an operating system’s implementation or interface. • Related Work • Hydra [Wulf et al ‘81] • Microkernels [Bershad et al ‘90] • Cross-Domain Communication [Hamilton & Kourgiouris] • “Little Languages” [Lee et al ‘94] • Code install in kernel at runtime [Heidemann & Popek ‘94] • Software fault isolation [Wahbe et al. 93] • Aegis[Engler et al. 95]

  7. SPIN STRUCTURE • SPIN architecture provides a software infrastructure for safely combining system and application code. • Protection Model • supports efficient, fine-grained access control of resources • Extension Model • enables extensions to be defined at the granularity of a procedure call • Relevant properties of Modula-3 • Interfaces, type safety, automatic storage management, objects, generic interfaces, threads, and exceptions.

  8. SPIN STRUCTUREPROTECTION MODEL • Controls the set of operations that can be applied to resources. • Capabilities: Unforgeable reference to a resource. • All kernel resources are referenced by capabilities • Resources are protected to ensure that extension reference the resources to which they have been given access • SPIN implements capabilities directly using pointers • A pointer can be passed from the kernel to user-level applications as externalized references

  9. SPIN STRUCTUREPROTECTION MODELCONT’D. • Protection domains • Defines a set of names, or program symbols, which can be referenced by code with access to the domain. • A domain, named by a capability, is used to control dynamic linking, and corresponds to one or safer object files. • Operations • Create: create a new domain • Resolve: dynamic linking • Combine: create a new aggregate domain

  10. SPIN STRUCTUREEXTENSION MODEL • Provides a controlled communication facility between extensions and the base system • Extensions in SPIN are defined in terms of events and handlers • The primary right to handle an event is restricted to the default implementation module for the event, which is the module that statically exports the procedure named by the event • Other modules may request that the dispatcher install additional handlers or even remove the primary handler • Dispatcher contacts primary implementation module. If denied installation falls • If allowed, the implementation module can provide a guard to be associated with the handler

  11. CORE SERVICES • SPIN provides a set of core services that manage memory and processor resources • The core services provided by SPIN are • Extensible memory management • Extensible thread management

  12. CORE SERVICESEXTENSIBLE MEMORY MANAGEMENT • A memory management system is responsible for the allocation of virtual addresses, physical addresses, and mapping between the two. • Components • Physical address service: controls use and allocation of physical pages. • Virtual address service: allocates capabilities for virtual addresses. • Translation service: expresses relationship between physical and virtual addresses.

  13. CORE SERVICESEXTENSIBLE THREAD MANAGEMENT • Application can provide its own thread package and scheduler that executes within the kernel. • SPIN doesn’t define thread model, instead defines structure upon which different threading models can be implemented. • SPIN use strands. • Operations: • Block • Unblock • Checkpoint • Resume

  14. PERFORMANCE • Platform • SPIN runs on DEC Alpha platforms • Measurements • DEC Alpha 133Mhz AXP 3000/400 works stations • Comparison system • MEC OSF/1 V2.1 (monolithic operating system) • Mach 3.0

  15. PERFORMANCE • Mirobenchmarks: 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

  16. PERFORMANCE • Microbenchmarks: Thread Management • Thread performance in spin was better than that of OSF/1 and Mach in the ping-pong and fork-join tests.

  17. PERFORMANCE • Microbenchmarks: Virtual Memory • Reasons for outperform • SPIN uses kernel extensions to define application specific system calls for virtual memory management. • Virtual memory event is reflected to the application through a fast in-kernel protected procedure call

  18. PERFORMANCE • Networking: Network Latency and Bandwidth • SPIN shows better network latency and bandwidth performance characteristics then OSF/1. • The application code executes in the kernel, where it has low-latency access to both the device and data.

  19. PERFORMANCE • 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.

  20. CONCLUSIONS • SPIN achieves performance in an extensible system without sacrificing safety. • SPIN provides a set of efficient mechanisms to extend services along with basic set of core services. • Programming languages with the appropriate feature support can be used to construct future operating systems

  21. QUESTIONS?

More Related