Some Linux I/O papers

Comparing and Evaluating epoll, select, and poll Event Mechanisms
Abstract
This paper uses a high-performance, eventdriven, HTTP server (the mserver) to compare the performance of the select, poll, and epoll event mechanisms. We subject the mserver to a variety of workloads that allow us to expose the relative strengths and weaknesses of each event mechanism.

Interestingly, initial results show that the select and poll event mechanisms perform comparably to the epoll event mechanism in the absence of idle connections. Profiling data shows a significant amount of time spent executing a large number of epoll_ctl system calls. As a result, we examine a variety of techniques for reducing epoll_ctl overhead including edge-triggered notification, and introducing a new system call (epoll_ctlv) that aggregates several epoll_ctl calls into a single call. Our experiments indicate that although these techniques are successful at reducing epoll_ctl overhead, they only improve performance slightly.

"...Interestingly, in this paper, we found that for some of the workloads considered select and poll perform as well as or slightly better than epoll..."

Scalable Network I/O in Linux
Abstract
Recent highly publicized benchmarks have suggested that Linux systems do not scale as well as other systems, such as Windows NT, when used as network servers. Windows NT contains features such as I/O completion ports that help boost network server performance and scalability. In this paper we focus on improving the Linux implementation of poll() to reduce the expense of managing large numbers of network connections. We also explore the newer POSIX RT signal API that will help network servers scale into the next decade. A comparison between the two interfaces shows that a server using our /dev/poll interface scales better than a server using RT signals.
---
[ i understand there is main paper about epoll mechanizm]
"...For the poll() interface to maintain performance comparable to the newer POSIX RT signal interfaces, it needs a face lift. We’ve enhanced poll() by making the following optimizations:
+ We provide an interface that maintains state in the kernel, so state doesn’t have to be passed in during every poll() invocation
+ We allow device drivers to post completion events to poll(), reducing the need to invoke device-specific poll operations when scanning for events
+ We eliminate result copying when poll() returns by creating a special address space mapping that is shared between the kernel and the application..."
"....Banga, Druschel, and Mogul have described new operating system features to mitigate these overheads [4]. They suggest that the poll() interface itself can be broken into one interface used to incrementally build an application’s interest set within the kernel, and another interface used to wait for the next event. They refer to the first interface as declare_ interest(), while the second is much like today’s poll(). Using declare_interest(), an application can build its interest set inside the kernel as connections are set up and torn down. The complete interest set is never copied between user space and kernel space, completely eliminating unnecessary data copies (for instance, when there is no change in the interest set between two poll() invocations).
---
Recent versions of Solaris include a similar interface called /dev/poll [6]. This character device allows an application to notify the kernel of event interests and to build a (potentially) very large set of interests while reducing data copying between user space and kernel space. As far as we know this is the first real implementation of declare_interest(). We chose to implement this because, if it is effective, it will allow easier portability of high-performance network applications between Solaris and Linux..."

A Scalable and Explicit Event Delivery Mechanism for UNIX
Abstract
UNIX applications not wishing to block when doing I/O often use the select() system call, to wait for events on multiple file descriptors. The select() mechanism works well for small-scale applications, but scales poorly as the number of file descriptors increases. Many modern applications, such as Internet servers, use hundreds or thousands of file descriptors, and suffer greatly from the poor scalability of select(). Previous work has shown that while the traditional implementation of select() can be improved, the poor scalability is inherent in the design. We present a new event-delivery mechanism, which allows the application to register interest in one or more sources of events, and to efficiently dequeue new events. We show that this mechanism, which requires only minor changes to applications, performs independently of the number of file descriptors.

Scalability of Linux Event-Dispatch Mechanisms
Abstract
Many Inte rn et se rve rs th e se days h ave to h andle n otjust h e avy request loads, but also incre asingly face large num b e rs of concurre n t connections. In th is pape r, we discuss som e of th e e ve n t-dispatch m e ch anism s used by Inte rn et se rve rs to h andle th e n e tw ork I/O ge n e rated by th e se request loads. W e focus on th e m e ch anism s supported by th e Linux k e rn e l, and m e asure th e ir pe rform ance in te rms of th e ir dispatch ove rh e ad and dispatch th rough put. Our com parative studie s sh ow th at POSIX.4 Real Tim e signals (RT signals) are a h igh ly e fficie nt m e ch anism in te rm s of th e ove rh e ad and also provide good th rough put com pared to m e ch anisms lik e select ( ) and /dev/poll. W e also look at som e lim itations of RT signals and propose an enh ance m e n t to th e default RT signal im ple m e n tation w h ich w e call signal-per-fd. Th is e nh ance m e n t h as th e advantage of significantly reducing th e com ple xity of a se rve r im ple m e n tation, incre asing its robustness under h igh load, and also pote n tially incre asing its th rough put. In addition, our re sults also sh ow th at, contrary to conve n tional w isdom , e ven a select ( ) base d s e rver can provide h igh th rough - put if its ove rh e ad is am ortized by pe rform ing m ore u s e ful w ork per select ( ) call.

Better operating system features for faster network servers
Abstract
Widely-used operating systems provide inadequate support for large-scale Internet server applications. Their algorithms and interfaces fail to efficiently support either event-driven or multi-threaded servers. They provide poor control over the scheduling and management of machine resources, making it difficult to provide robust and controlled service. We propose new UNIX interfaces to improve scalability, and to provide fine-grained scheduling and resource management.