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: Performance Evaluation
Up: A Scalable Locality-Aware Event
Previous: Introduction
2003-03-23