Transcript 12bx

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
• 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 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
• 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
• 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
• 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
• 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
• 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
• 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
•
•
•
•
•
•
•
•
•
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
•
•
•
•
•
Manage memory
Manage processes
Pretty much it
Fairly vanilla setup
Lot’s of small operations
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
• 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
•
•
•
•
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
•
•
•
•
•
System Size
Microbenchmarks
Networking
End to end performance
DEC Alpha, 133 MHZ, AXP 3000/4000, 64 MB
ram, 512kb cache, 1 gb diskdrive, 10mb/sec
ethernet, 155 mb/sec ATM adapter(?)
• Single user mode
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
• 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
• 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
• 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
• 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