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

        o 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.
        o Capability systems consist of fine-grained objects sharing an
          address space but with their own protection domains. These offer
          flexibility, modularity, and protection.
        o The common case for communication is between domains on the same
          machine as opposed to across machines.
        o 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).
        o 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:

        o 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?).
        o 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.
        o 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.
        o 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:

        o 3X speedup for single processor.
        o 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