spin design contention between safety extensibility performance
Skip this Video
Download Presentation
SPIN: Design Contention between Safety-Extensibility-Performance

Loading in 2 Seconds...

play fullscreen
1 / 20

SPIN: Design Contention between Safety-Extensibility-Performance - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' SPIN: Design Contention between Safety-Extensibility-Performance' - fawzi

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
spin design contention between safety extensibility performance

SPIN: Design Contention between Safety-Extensibility-Performance

Review of Extensibility, Safety and Performance in the


Operating System

By Lewis Coates

some preamble
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.
modula 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
more modula 3
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…?)
way too much on modula 3
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.”
primary goals
Primary Goals
  • Co-Location-for performance and safety
  • Logical Protection domains (protected virtual memory spaces)
  • Dynamic Call binding (fast system calls?)
no one has gotten the holy grail yet
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
  • 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
protection domains
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
  • 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
core services
Core services
  • Manage memory
  • Manage processes
  • Pretty much it
  • Fairly vanilla setup
  • Lot’s of small operations
extensible memory management
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)
extensible thread management
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
trusted services
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
  • 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
enter the strawman
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
  • 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
microbenchmarks extended
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
  • 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)
  • 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