Back to index
Scout: A Communications-Oriented OS
Alan B. Montz, David Mosberger, Sean O'Malley, Larry Peterson, Todd
Proebsting, John Hartman
One-line summary: Communication-centric information appliances
need an OS based on a communication path (bytes from application to network)
as a first-class abstraction; scheduling of CPU, cache, TLB, etc. should
be based on this abstraction, resulting in scalable and predictable
communication behavior. Also, language & compiler optimizations should
target OS code, which although different from application code exhibits
optimizable patterns of its own.
- OS for "small" devices should be configurable; no need for
full generality on all platforms.
- The communication "path", including all hardware and software
involved in communication right up to the application, is a first-class
abstraction around which resource allocation, cache management, and path-based
optimizations are done. (Compare in X-kernel: a shepherd allows
a single comm task to cross address spaces/protection boundaries.)
- The result should be communication performance that is both scalable
and predictable, so Scout has some application as a real-time OS.
- Compiler technology should target OS-specific patterns; e.g. automated
generation of tedious low-level code.
- Universal Protocol Compressor: exploit semantic knowledge of data being
communicated to achieve protocol-specific compression, by requiring programmer
to annotate protocol data structures.
- Integrated layer processing: collapse protocol layers to remove redundant
copies, allowing a single pass over each packet for FEC, checksumming, decompression,
etc. Previous work: Increasing Network Throughput by Integrating Protocol
- Dynamic code generation to produce highly-optimized path-related code
sequences. Compare to the Synthesis Kernel.
Like all good ideas, obvious in retrospect: by making the communication
path the central point of the OS, we can make its performance predictable,
if possibly at the expense of predictability in other areas. (Compare:
relationship between macro and micro benchmarks for caches and CPU's is
much better understood than it is for networks, since the scheduling and
other facilities provided by the OS are usually orthogonal to the communications
facilities and thereby have complex interactions with them. Cf. Ousterhout,
Why Aren't Operating Systems Getting Faster as Fast as Hardware?)
- Comm-centric paths abstraction and compiler optimizations seem to be
orthogonal, except for runtime code generation for optimizing comm paths.
This has been shown to be hard; Synthesis Kernel did it only for a "fake"
OS (e.g. no VM).
Back to index