Evaluations: 05/18

Bianca Zadrozny (zadrozny@cs.ucsd.edu)
Wed, 17 May 2000 23:55:04 -0700

Lightweight Remote Procedure Call

This paper describes the Lightweight Remote Procedure Call (LRPC) facility, which is a communication mechanism that is adequate for communication across protection domains that are located on the same machine. LRPC provides the programming semantics and large-grained protection present in RPC systems, while having an execution model that is borrowed from protected procedures calls in systems with capabilities.

The paper demonstrates experimentally that most communication traffic in operating systems occurs across domains in the same machine, and that it usually involves small parameters rather than large data structures. Furthermore, it shows that traditional RPC is inefficient in these cases. Thus, the LRPC mechanism is proposed, with the goal of achieving the same safety and transparency of RPC while increasing significantly its performance in such cases.

The performance achievement of LRPC is based on optimizations that are possible because the client and server are assumed to be located in the same machine. One example of such an optimization is to have client and server share the same argument stack, which reduces the number of copy operations. Another example is to allow the client's thread to execute in the server's domain. The paper also suggest an optimization in the of a multiprocessor machine. Basically, the context switch overhead can be minimized by caching domains on idle processors, and using processors idling in the server domain to execute calls.

I liked this paper because the proposed design is based on assumptions that are demonstrated experimentally to be valid. Moreover, the design decisions are very logical given these assumptions. The paper is also very well written. It begins by giving the motivations to the work and showing the weaknesses of other approaches. Then, it thoroughly describes the approach taken. In the end, it gives good performance results.


Active Messages: a Mechanism for Integrated Communication and Computation

This paper introduces a communication mechanism in which each message carries a reference to a user-level handler that is responsible for extracting the message from the network and integrating it into an on-going computation. This communication mechanism is intended for use in large-scale multiprocessors, since it reduces communication overhead by overlapping communication with computation.

In current message passing systems such an overlap is attempted by the use of non-blocking send and receive operations. However, this approach forces the kernel to manage buffers that store messages. This results in a very high start-up cost, which prevents the desired overlap in most cases (except for large messages). On the other hand, blocking send/receive operations do not require any buffering but intrinsically prevent the overlap by synchronizing the communicating parties. Active Messages tries to achieve the simplicity of a blocking send/receive communication model, while allowing the overlapping of communication with computations.

By requiring that the user-level handler that extract messages from the network execute very quickly, it is possible to avoid buffering of messages in the kernel. This reduces the start-up cost of communication, thus making smaller messages more attractive, which facilitates program development and reduces network congestion.

The paper describes a fine-grained parallel execution model based on Active Messages, which is a compilation target for implicitly parallel languages. In this system, the compiler can improve the locality of reference by synchronizing in message handlers and enabling computation only when a number of messages have arrived. The paper also points out some improvements that could be done to network interfaces and processors in order to reduce the overhead of composing and receiving a message.

In my opinion, the idea of active messages is very interesting because it puts together good characteristics from both message-based and procedure-based system, in order to achieve good performance in the case of multiprocessors. However, I do not think that the paper is very well written, since it is difficult to understand how the scheme works and how it could be applied in practice.