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.

Overview/Main Points

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 Layers.
Dynamic code generation to produce highly-optimized path-related code sequences. Compare to the Synthesis Kernel.

Relevance

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?)

Flaws

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