Normally the Remote Memory Pager (RMP for short) is a multi-threaded client which forwards the paging requests to a remote server, via sockets over an Ethernet. Our first prototype implements a single remote memory server system used to evaluate the performance of remote paging. The RPM connects to the remote memory server using a socket over TCP/IP. One client thread issues page-in and page-out requests to the server, while a second client thread accepts the data sent by the server.
RPM is also capable of forwarding the requests to the local disk using either a specified partition or a file. In the former case, it invokes a routine that places the request in the disk queue. In the later case it issues a read or write operation through the VFS layer routines. When no server can be found in order the client's requests, paging to local disk is used.
Although the current implementation runs on top of a slow 10 Mbps Ethernet, remote paging is up to 2 times faster than using a local disk of the same bandwidth. It takes about 8.7 ms to transfer an 8KB page through the network, while transferring a page to/from the local disk takes about 17 ms. Faster networks such as ATM, or FDDI should offer even more promising performance, especially when faster communication protocols are used [18]. For the time being our performance results suggest the communication protocol latency for page transfers rarely exceeds 5%, even for 100 Mbits/sec networks.
Although bus-based networks will eventually become a performance bottleneck, the single link ensures that every request can reach every interested host. This means that the implementation of reliability using mirroring of parity, can be rather simple. A second prototype, still under development, uses mirroring in order to ensure the integrity of the pages transferred even when a server crashes. It also scatters the paged out pages to many servers in order to give the operating system the illusion of a swap device of high capacity. A dedicated RPM thread uses a socket to broadcast each request. A second thread waits until some server replies to the pending requests. A server in this case may be primary or backup. In case of a primary server crash, the second thread will soon be informed, based on a timeout mechanism, and will ask the backup server responsible for the pages maintained by the crashed server to fulfill its requests.