Yu Xu (yxu@cs.ucsd.edu)
Wed, 17 May 2000 21:26:52 -0700

Evaluation of " Lightweight Remote Procedure Call "

The main goal of LRPC is to optimize the communication between protection
domains on the same machine. LRPC achieves a factor of three performance
improvement over more traditional approaches.

The most obvious feature of LRPC is that it combines the control transfer
and communication model of capability systems with the programming semantics
and large-grained protection model of RPC. The paper shows that most
communication traffic in operating systems is between domains on the same
machine and simple.

Four techniques contribute to the performance of LRPC: Simple
control transfer, simple data transfer, simple stubs, design for

Some important features of LRPC's design and implementation include:
1.The Binding Object gives safety in binding in LRPC. Dynamic
A-stack/E-stack association utilizes server address space efficiently and
offer safety and performance.
2.Stubs are not portable, but stub generator can be ported.
3. LRPC reduce latency by caching domain contexts on idle processor. This
greatly reduce the context-switching overhead.
4. Argument copying are reduced to as many times as necessary by suing
pair-wise allocation of A-stacks.

LRPC use name server to register server interfaces. In Birrell's paper ,
their RPC depends on grapevine's distributed database. So, it seems LRPC
has better portability.

Evaluation of " Active messages mechanism for Integrated Communication and

This paper proposes the Active Messages model to integrate communication
computation at low cost.

The basic idea of Active Messages is that each message contains at its head
the address of a user-level handler which is executed on message arrival
with the
message body as argument. The efficiency of this model comes from the
elimination of buffering beyond network transport requirements, the simple
scheduling of non-suspensive message handlers, and arbitrary overlap of
computation and communication.

Message passing machines devote most of their hardware resources to
processing, while message driven machines devote most of their hardware
resources to message transmission, reception and scheduling. The Active
model tries to balance the two aspects by providing the ability to overlap
communication and computation and to reduce communication overhead.

The key difference between Active messages with the message driven model is
where computation-proper is performed and whether the handler has the
ability to
suspend. Basically, the Active Messages model captures the essential
functionality of message driven machines with simpler hardware mechanisms.

Active Messages on the nCUBE/2 and on the CM-5 shows the model's good
performance. Active messages can get hardware support from two categories:
improvements to network interface and modifications to processor to
execution of message handlers.