Extensibility, Safety and Performance in the SPIN Operating System

1. Extensibility, Safety and Performance in theSPIN Operating System Ashwini Kulkarni Operating Systems Winter 2006

2. 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

3. 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

4. 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

5. 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

6. 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.

7. Motivation, Goals & Approach Extensibility Generic Operating System Module C Module A Module B Application Specific Extensible modules Safety Performance

8. 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

9. 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

10. 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

11. 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.

12. 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

13. SPIN Safety - Protection Domains

14. 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.

15. SPIN – Extensibility Model REF: Flexible Event Handling for an Extensible Operating System, Przemyslaw Pardyak, OSDI 94, November 1994

16. 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

17. SPIN - Core Services SPIN Memory Management Unit / Interface

18. 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

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

20. SPIN - Core Services SPIN Thread Management Interface

21. 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.

22. 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 Virtual Memory Management Thread Management

23. 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.

24. 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