Check out the new USENIX Web site. next up previous
Next: Delegated RPC Up: Page Transfers in GMS/Trapeze Previous: Basic Mechanisms

   
Zero-Copy Reply Handling

GMS performance depends on efficient handling of getpage replies containing page payloads. When the virtual memory system or file system initiates a page fetch, it first selects the target page frame according to its policies for page replacement and other factors such as page coloring. The goal of the GMS getpage client stub is to arrange to transfer the incoming page directly to the waiting frame using DMA.

The RPC system uses the Trapeze incoming payload table (IPT) described in Section 2.3 for this purpose. The client-side getpage stub calls Trapeze to allocate an IPT entry and obtain a payload token, which is added to the reply token for the call. When the server-side getpage stub generates a reply, it attaches the frame containing the requested page as a payload, extracts the Trapeze payload token, and tags the outgoing reply message by placing the token in its Trapeze header. Back on the client side, the Trapeze firmware recognizes the tag in the message header as the reply payload begins to arrive on the adapter; once the tag is decoded and validated, the firmware initiates DMA of the message payload into the waiting frame.


  
Figure 3: GMS getpage operation through a directory site using a delegated RPC.
\begin{figure}
\vspace{0.1in}
\centerline{\epsfig{file = figs/getpage.eps, width = 2.5in}}
\vspace{.1in}
\end{figure}


next up previous
Next: Delegated RPC Up: Page Transfers in GMS/Trapeze Previous: Basic Mechanisms
Darrell Anderson
1998-04-27