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, and Susan Eggers. ----------------------------------------------------------------------- OVERVIEW: --------- SPIN is an OS that can be dynamically specialized/extended by applications. - Many implementation decisions in the OS (paging algorithms, cache replacement algorithms, etc.) are poorly matched to the needs of some applications (databases, multimedia apps, parallel apps, and others--if your OS can't perform well for all apps SPIN provides - Extensibility: determined by the abstractions/interfaces exported by the OS. We want low-level abstractions (close to HW) - Safety: applications should still be protected from each other. Access to resources is controlled at the same level that extensions are defined at. - Good Performance: extensions should have a low-overhead way of communicating with the SPIN system. How to do this: - SPIN solution is to allow applications to place app-specific kernel extensions into the kernel. Extensions must be verified for safety by the Modula compiler. Because the extensions don't need to cross a kernel/user level boundary, communication overhead is low (and performance is high). Related Work: - tons of related work. Microkernels, Aegis, etc. Lots of people try to write extensible kernels, but most give up either safety, performance, or "real" extensibility. ARCHITECTURE: ------------- Modula-3 - extensions are written in Modula-3. - Key features for SPIN are: interfaces, type safety, automatic storage management. - Also useful (but not necessary) is: objects, generic interfaces, threads, and exceptions. - Design of SPIN depends on language's safety and encapsulation mechanisms (type-safety, checks on use of pointers, etc.) Protection Model: - Capabilities: Kernel resources in SPIN are referenced by capability. Capabilities are implemented with pointers (unforgeable due to use of Modula-3). - Protection Domain: To protect extensions from each other, use namespaces (extensions can only get to things they can name). This naming/protection is done at compile-time and link-time by the language. When dynamically linking extensions to the system, SPIN checks protections... Extension Model: - Events/Event Handlers: Extensions are defined by registering handlers for events. Events include changes in the system (page is free), and requests for service (allocate a page). - The default handler for an event can allow (or not allow) an extension to register a handler for an event. It can also post guards on extensions, to allow the handler to handle only some events of a given type (e.g., only TCP packets) - Multiple handlers may be registered for an event. All will be called, in an undefined order. CORE SERVICES ------------- Memory Management: SPIN exports three low-level services for mem mgt. SPIN does not define an address space, or memory model, but extensions can, using these primitives. - Physical Address Service: controls use and allocation of physical memory (allocate, deallocate, reclaim). - Virtual Address Service: controls allocation and deallocation of virtual addresses - Translation Service: controls TLB, mappings between VA and PA. Extensible Thread Mgt: - Strand: a strand is SPIN's unit of scheduling, but unlike threads, has no kernel state associated with it (other than its name). - Extensions define what happens when a strand is blocked, unblocked, checkpointed and resumed. App-specific extensions can determine what application thread might actually run when a particular strand is scheduled. Trust: note that core services are trusted. MEASUREMENTS: ------------ System Size: - SPIN itself is not large, and extensions can be very small. Microbenchmarks: - compare SPIN to Mach and DEC OSF/1 - measure protected communication: SPIN's extension-to-system calls are much faster than others. It beats the pants off of traditional system calls. SPIN's implementation of system calls and cross-address space calls are also much faster - thread management: a number of benchmarks show SPIN is a fair bit faster at running ping-ponging threads. - Virtual Memory: several common VM benchmarks show SPIN is faster than others. Reasons: 1) kernel extensions define app-specific behavior for vm mgt. 2) Each VM event no longer needs to cross kernel/app boundary. It all happens through in-kernel procedure calls. Networking: - Latency and Bandwidth: Latency improves when extensions are in the kernel. Bandwidth doesn't improve noticeably. - protocol forwarding: by putting TCP forwarding extension lower in the network stack, we can avoid breaking end-to-end, and also have better performance. End-to-End performance: - Implemented Video Server/Client and saw significant performace improvements from specialized extensions to copy data directly from disk to network, and network to video buffer. - Web Server: extensions allowed server to control disk caching to avoid double buffering. ISSUES: ------- Scalability: Having too many handlers and guards on events might not scale. Automatic Storage Mgt: SPIN needs garbage collection to ensure that old pointers can't be maliciously reused. But if too much memory is cycled, then the GC gets triggered too often, hurting performance of other apps. Partial solution is to avoid memory allocation requests on fast path through system. QUESTIONS --------- * If it's faster to put stuff in the kernel, and we can put (almost) arbitrary extensions into the kernel safely, why not put the whole app inside the kernel? (and get rid of the whole kernel/userspace division) * How does SPIN compare to kernel modules today? (modules aren't "safe", but a number of programs do extend the kernel using modules, e.g., VMWare).