next up previous
Next: Performance Evaluation Up: A Scalable Locality-Aware Event Previous: Introduction


Temporal-locality-aware poll

The idea of temporal-locality-aware poll() is: Since a descriptor is idle most of the time, it doesn't need to be polled at every poll loop. It should be polled only when it is likely to have events recently. Events can be predicted based on the history of a descriptor. We approximate this by associate a counter with every descriptor. In a poll loop, the counter is increased if there are events, otherwise, it is decreased. All descriptors are divided among three polling sets according to this counter. The frequency of calling poll() to the kernel of each set is different. In this way, polling time on most idle descriptors is saved and active descriptors are checked more efficiently. Our library is a user-mode library, sitting between server application and kernel system call. We named it FDM (File Descriptor Management Library), because its goal is to manage all file descriptors in a server application. During the life time of file descriptors, file descriptors are kept in one of three polling set in the library, and are polled by library according to its live counter. Figure 1 illustrates the architecture of the library.


Figure 1: Architecture view of event dispatching library

Given a file descriptor, server application may interest in reading it or writing it, but not both. For example, before server reads HTTP request from a file descriptor, it waits for read ready event of the descriptor. After it gets read ready event and reads HTTP request, it waits write ready event of the descriptor before writing HTTP reply. Server application must specify current interest (read or write) before calling fdm_wait_event(). This is achieved through fdm_update_fd_mode(). Current interest of a file descriptor is specified in events field of fds argument. In general case, server application may need to maintain an array or a hash table to keep track of the association between a file descriptor and the threading or call-back data structure of a connection (These data structure are needed in a SPED server). When some events are returned from kernel, file descriptors of returned events are searched throughout the array for their threading or call- back data structure. Server needs a threading (or call-back) data structure to resume the execution of a thread (call-back function) that deals with a specific connection. To remove the need for the server application to maintain another array and to eliminate the linear search mentioned above, the data structure for a file descriptors maintained in the library has a payload field that saves the address of associated threading or call-back data structure. Every event returned also carries a payload field, payload is a void pointer that can point to anything like threading or call-back data structure. In addition, server applications may need to close a timeout connection if it is idle for a long time. This feature support is needed in this library in order to remove another time-stamp array (also the corresponding linear search) in server code. Both of the threading (call-back) data structure and the timeout time- stamp of a file descriptor can be updated through the arguments of fdm_update_fd_mode().
next up previous
Next: Performance Evaluation Up: A Scalable Locality-Aware Event Previous: Introduction
2003-03-23