read()call on /dev/sskm to allow SSD to read from event queue and take appropriate actions for each event.
sskm_bh()that executes after receiving a packet from HSN's interrupt service routine and deals with reception and processing of packets intended for SSKM.
This page describes the common structure of the messages exchanged between the CSKM and the SSKM.
This is the structure of events exchanged between SSKM and SSD.
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.
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.
SSKM psuedo-device operations
"sskm_fops" structure in this page describes the structure of operations that can be performed on the SSKM psuedo-device.
"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.
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.1 SSKM Initialization Operations
register_chrdev()call. Mark the device as not yet opened by an SSD by setting to zero the
open()call made by SSD on the SSKM psuedo device.
sskm_statusstructure. Set the process id of the owner of the device to that of the SSD which made the
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
structure. Depending upon the type of message received, one of the
following actions are taken.
insert_page()routine is called to insert the page received into server cache. Depending on whether routine returns a success or failure, a positive or negative pageout reply message is constructed and handed down to HSN layer for transmission to client. More description here .
request_page()routine is called. If this routine returns with a successful page lookup status, the retrieved page is sent back to the client as a packaged message. If the lookup routine returns the status that the page is on disk, an event is generated to inform the SSD to bring in the page from the disk into server's cache. Pagein reply is postponed till the page is placed in the cache. If the routine returns with an error status that page is not stored on this server, the message is quietly dropped and no further action is taken. More description here .
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
request_info, from cache (or secondary store). It is called in response to page-flush message received by SSKM from the SSD which in turn receives this message from CSD over fast-ethernet.
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
- Called from interrupt service routine myri_receive_datagram().
- Queues the payload into SSKM queue
- mark_bh(SSKM_BH) - marks the sskm_bh() bottom half for later execution.
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 :
4.6 SSKM Shutdown Operations
The following shutdown operations are carried out when the SSD makes a
call on the SSKM device or when the machine reboots with SSKM device open.