Server Side Kernel Module
(last updated 05/07/99)
Kartik Gopalan

1. Overview
This module is responsible for handling pagein and pageout requests arriving from client systems and responding to them with minimum possible latency. It consults the SSCM to determine whether pages are currently resident in the NMS cache. It also generates an event stream consumed by the SSD. Thus SSKM is structured as a reactive module which responds to commands from user processes and to events from interrupt routines.

2. Interfaces
This module consists of the following components.

3. Data Structures

3.1 Message Structure
This page describes the common structure of the messages exchanged between the CSKM and the SSKM.

3.2 Event Structure
This is the structure of events exchanged between SSKM and SSD.

3.3 Request Information
The request_info structure holds comprehensive information about a received request. It is used internally by SSKM for conveniently passing around entire request information while handling both page-in and pageout requests.

3.4 SSKM psuedo-device status
"sskm_status" structure in this page describes the status of the SSKM psuedo-device (/dev/sskm). The structure indicates whether the SSKM device is open or closed and gives the process id of the owner SSD process.

3.5 SSKM psuedo-device operations
"sskm_fops" structure in this page describes the structure of operations that can be performed on the SSKM psuedo-device.

3.6 Client Information
"client_info" structure in this page describes the per-client information stored in the server. The "client_table" hash table of these structures stores information about all clients having an open session with the server and is hashed into using the client ID.

3.7 Session Information
A global session ID identifies the current session ID that is sent with every message transmitted by the server on myrinet. Current per-client session ID is stored in the client_info struct for that client and is accessed through the client_able. See "Tracking Client and Server Status" for more information on how sessions are managed.


4. Design

4.1 SSKM Initialization Operations

4.2 SSKM bottom half routine
The SSKM bottom half routine sskm_bh() executes just above HSN interrupt service routine. Whenever packets intended for SSKM are received, they are placed in a queue by the sskm_rcv() routine which also marks the SSKM bottom half for execution. The definitions for queue structure is described here. Upon return from the interrupt service routine, the bottom half gets to run and picks up the packets from the queue and processes them. First of all the routine examines the message received and packages the information into a request_info structure. Depending upon the type of message received, one of the following actions are taken.


4.3 Interface between SSKM and SSCM
The SSCM exposes a set of functions to SSKM which are called at appropriate times.

Interface for handling client pagein requests

Interface for handling client pageout requests Interface for handling page freeing

4.4 Interface between SSKM and HSN driver

Reception of SSKM data
void sskm_recv(char *payload, int payload_length)

Sending SSKM data to a destination
For any message to be sent to another host, SSKM calls one of the function interfaces provided by HSN driver and passes its payload and payload length as parameters. Note about payload : The payload consists of page_data(8k or 4k) followed by a trailer ( NOT the other way around as in header followed by page_data). This is because, page_data needs to be transmitted by HSN driver aligned at 4k boundary so that copying can be avoided at the receiving end.

4.5 Suspension and Resumption of SSKM Operations
Whenever the critical event queue between SSKM and SSD becomes full, the SSKM suspends reception of any further requests over HSN link until SSD clears the backlog events from the queue. This action is necessary since the events might include requests to SSD to bring in client pages from backing store to server cache. Dropping these critical events is not an option here unlike in the case of non-critical events. Hence suspension of further client reqyest processing is the only recourse available under these circumstances. The suspension operation involves the following steps :

When the free space in critical event queue is restored to normal, the SSKM operations are resumed again by executing the following steps :

4.6 SSKM Shutdown Operations
The following shutdown operations are carried out when the SSD makes a close() call on the SSKM device or when the machine reboots with SSKM device open.