Lightweight Remote Procedure Call
Bershad, Anderson, Lazowska,
and Levy
One-line summary: This paper presents a lightweight communication
facility (based on RPC) designed to handle communication between protection
domains on a single machine.
Overview/Main Points
- The Case for Lightweight RPC (LRPC):
- Monolithic kernels are insulated from user programs, but few protection
boundaries exist within the OS itself, which makes it difficult to modify,
debug, and validate.
- Capability systems consist of fine-grained objects sharing an address
space but with their own protection domains. These offer flexibility,
modularity, and protection.
- The common case for communication is between domains on the same machine
as opposed to across machines.
- Most communication is simple, involving few arguments and little data,
since complex data is often hidden behind abstractions (Both this and the
above point were backed with some questionably representative examples).
- While RPC is robust enough to handle both local and remote calls, it has
high overhead. A lighter weight solution is necessary.
- Lightweight RPC features:
- Simple control transfer: Conventional RPC involves multiple
threads that must send signals and switch context. In LRPC, the kernel
changes the address space for the caller's thread and lets it continue to
run in the server domain (at the same priority?).
- Simple data transfer:Shared buffers are pre-allocated (when the
caller imports the LRPC module) for the communication of arguments and
results. The caller copies the data onto the A-stack, after which no other
copies are required.
- Simple stubs: RPC has general stubs, but many of its features are
infrequently needed. LRPC uses a stub generator that produces simple stubs
in Modula2+ assembly language.
- Design for concurrency:Idle processors in multi-processor
machines cache domain contexts to reduce context-switch overhead. Counters
are used to keep the highest activity LRPC domains active on idle
processors.
- Performance:
- 3X speedup for single processor.
- Additional speedups for multiprocessor machines.
Relevance
This paper offers an optimization that can be used to
significantly improve the structure of operating systems through improving the
common case of local cross-domain calls (with simple data). In general, their
techniques and results seem useful and valuable.
Flaws
- How language dependent are their policies/code?
- Are the machines represented a good slice of what was available?
- Has the ratio of remote to local RPCs changed at all with the increase in
networking? How commonly is RPC used?
Back
to index