1 / 20

SPIN: Design Contention between Safety-Extensibility-Performance

SPIN: Design Contention between Safety-Extensibility-Performance. Review of Extensibility, Safety and Performance in the SPIN Operating System By Lewis Coates. Some Preamble. Discusses an operating system on a DEC Alpha Written circa 1994-95, so in competition with L3 and MACH

fawzi
Download Presentation

SPIN: Design Contention between Safety-Extensibility-Performance

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. SPIN: Design Contention between Safety-Extensibility-Performance Review of Extensibility, Safety and Performance in the SPIN Operating System By Lewis Coates

  2. Some Preamble • Discusses an operating system on a DEC Alpha • Written circa 1994-95, so in competition with L3 and MACH • Although Mach would be abandoned almost as this paper was coming out • Modula 3 appeared roughly 1988, so was a somewhat mature Programming language • DEC was acquired in 1998 which would largely make both Modula 3 and the Alpha (and by extension SPIN) irrelevant.

  3. Modula 3 • Modula 3 is a (very) late successor to Pascal • Very reminiscent of modern Java, or especially C# • Much of the design decisions were leveraged in C# and more recent versions of Java • Used to implement the Kernel, but code in the applications can be anything (a UNIX server was written in C…surprised? No? Bueller?) • Was a major point of design decision

  4. More Modula 3 • Kernel relies on some data hiding properties of modules • Strong, static typing (yes, I know that’s ambiguous) • Automatic Storage management (Garbage Collection in common vernacular) • Index bounds checks (and on error…?)

  5. Way Too Much on Modula 3 • Originally the team (all C coders) tried to make a new version of C that had garbage collection, objects, richer type system etc. etc. • They Failed. Like everyone else. • Switched to Modula 3 Because it has no noticeable performance degradation (citation needed) • And because C programmers can learn it in 3 days (citation very much needed) • “Although anecdotal, our experience has been that the portions of the SPIN kernel written in Modula-3 are much more robust and easier to understand than those portions written in C.”

  6. Primary Goals • Co-Location-for performance and safety • Logical Protection domains (protected virtual memory spaces) • Dynamic Call binding (fast system calls?)

  7. No one has gotten the Holy Grail Yet • Hydra-good performance and protection, terrible extensibility • L3/other microkernels, excellent performance, great extensibility, questionable performance • “little language” based extension-confusing and difficult • Arbitrary code execution-fantastic performance, unparalleled extensibility, literally no protection • Software fault isolation-not yet discovered (simultaneous with this paper) • Pilot-written in MESA, relied on MESA for all programs in the system, not just Kernel. Extensibility great…if you force everyone to learn MESA • MS-Dos-Got none of it in exchange for nothing

  8. Capabilities • The Kernel API is built around an abstraction called “capabilities • Virtual memory system, for example • Different protection domains to allow different extensions different levels of visibility • Exposed as typed pointers to blocks of • Can be externalized, each application has a table of indexes into the kernel, pass the index of the reference in the table corresponding to the service in the kernel

  9. Protection Domains • At the language level, not virtual memory • Defines a set of names, symbols, etc. that can be referenced by anyone with access to this protection domain • Safe if signed by kernel, or asserted (C libraries, binary blobs) • Domains can be intersecting, disjoint

  10. Extensibility • Scheduler, Page manager etc. • Events and handlers, events messages, handlers receivers • Handlers registered at a dispatcher • Event is a procedure exported from an interface, handlers are procedures of same type • Pre-emptive, handlers can’t take over • Raising an event = calling a procedure • Delegation of authority for control • Guards are a finer granularity then by name, useful i.e. in TCP/IP • Asynchronous, multiple handlers, you name it, probably possible

  11. Core services • Manage memory • Manage processes • Pretty much it • Fairly vanilla setup • Lot’s of small operations

  12. Extensible Memory Management • Pretty much the same as any other • Storage, naming, translation are the three services • Use these to make whatever you want (for example UNIX like address space semantics)

  13. Extensible Thread Management • Every application can declare it’s own scheduler and thread library, which runs in kernel space • Each context a strand, like a thread context, but no kernel state other than a name • Synchronization and thread management of the kernel, is the kernels (safety) • Checkpoint, resume, block, unblock

  14. Trusted Services • Core services are “trusted” • Allowed to control the Kernel • Access hardware • extension can blow themselves up by corrupting thread definitions etc. • Isolated to that extension

  15. Performance • System Size • Microbenchmarks • Networking • End to end performance • DEC Alpha, 133 MHZ, AXP 3000/4000, 64 MB ram, 512kb cache, 1 gbdiskdrive, 10mb/sec ethernet, 155 mb/sec ATM adapter(?) • Single user mode

  16. Enter the Strawman • These performance characteristics are basically useless as presented • Difficult for me to extract meaningful information and comparisons to L3/L4 since they don’t post syscall times, or other competing Items on the same hardware • Basically saying they are doing better than people who didn’t do very well

  17. Microbenchmarks • 65K lines of code • 447 kb • Protected Communication is faster than either OSF/1 (by a lot) or Mach (by some), and system calls are on par with OSF/1 (Mach is almost twice as slow) • Protected in kernel call (fast), not available in either competitor

  18. Microbenchmarks Extended • Thread management in Kernel was dramatically faster for Fork Join than either OSF/1 and MACH, basically across the board by a factor of 5-10 • Ping Pong was also dramatically faster (3-5x) • Showed that you can use a user level thread library without performance penalty in user space • Memory is dominatingly faster because of application specifc system calls for virtual memory, and in kernel protectd procedure

  19. Networking • Once again dramatically faster then the competition across the board in latency, bandwidth, throughput, scalability • Basically a godsend to everyone because it’s so perfect • Totally not because it’s simply better implemented (for example, supports DMA)

  20. Other • Dispatcher is a huge hotspot on all event performance paths • Particularly with guards • Garbage collector has specific design parameters (not allocating lots of little objects) • Extensions relatively small (which is nice) • Also quite modular

More Related