Spin design contention between safety extensibility performance
This presentation is the property of its rightful owner.
Sponsored Links
1 / 20

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


  • 69 Views
  • Uploaded on
  • Presentation posted in: General

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

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

SPIN

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


Capabilities

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


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


Extensibility

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


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


Performance

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


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


Microbenchmarks

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


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


Networking

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)


Other

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


  • Login