CS262A Reading Summary 30

Lightweight Remote Procedure Call

B. N. Bershad et al.
Summary by Feng Zhou
11/12/2002

1. RPC is a good way to modularize software systems, achieve network transparency and protect different part of the system from interfering with each other. However, it is argued that most RPC calls are within the machine boundary. Therefore conventional way of implementing it through message passing is suboptimal for the common case, which is a bad thing.
2. LRPC makes cross-domain (same machine) RPC calls faster by exploiting memory sharing functionality provided by OSes. It is claimed that LRPC "utilizes the control transfer and communication model of capability systems". In my understanding, this refers to the fact that in capability systems (systems with ticket-based security models?), every operation is mediated by the kernel while the arguments are directly passed to the destination, which is exactly how LRPC works.
3. Apart from the straightforward basic idea, LRPC employs several optimizations. First is the use of A-stack and E-stack. In languages with a explicit parameter pointer, this obviates one copy of the arguments. However, this also brings complexities when passing things by reference. Another optimization is LRPC reduces context-switch overhead by caching domains on idle processors, which is applicable (and acutally used by) multi-processor OSes in general. This effectively hides context switching latency and improves TLB and cache locality.

It seems possible to me to further reduce kernel mediation in local RPC calls without compromising protection. The binding/argument validation processes can be done at server side, while the invocation/argument passing can be done through pairwise shared memory. The kernel provides a yieldTo call that transfers control from the client to the server when the RPC happens, and vice versa when it returns. This will be at least as fast as LRPC while be mostly implemented in userland, which can be more easily maintained and improved.