Information Technology Reference
In-Depth Information
Buffer descriptors and high-performance I/O
In early computer systems, the key to good performance was to keep the processor
busy; particularly for servers, the key to good performance today is to keep I/O devices
such as the network and disk device busy. Neither Internet nor disk bandwidth has kept
pace with the rapid improvement in processor performance over the past four decades,
leaving them relatively more important to system performance.
If only one network or disk request is outstanding at a time, interrupt handling can be
the limiting factor. When a device completes a request, it raises an interrupt, triggering
the operating system to make a new request. In the meantime, while the processor is
handling the interrupt, the device is idle, when it could be putting the next request on
the network or sending it to disk.
The solution in modern systems is for the operating system to set up a circular queue
of requests, one for incoming and outgoing, for each device to handle. Each entry in the
queue, called a buffer descriptor, specifies one I/O operation: where to find the buffer to
put the incoming data or fetch the outgoing data, whether to take an interrupt on every
packet or only every few packets, and so forth. This decouples the processor and the
I/O devices, so that each only needs to keep up with the average rate of I/O events.
Buffer descriptors are stored in memory, accessed by the device using DMA (direct
memory access). An implication is that each logical I/O operation can involve several
DMA requests: one to download the buffer descriptor from memory into the device, then
to copy the data in or out, and then to store the success/failure of the operation back
into buffer descriptor.
misbehaving user programs, it is essential that applications trap only to a
pre-dened address | they can not be allowed to jump to arbitrary places
in the kernel.
Operating systems provide a substantial number of system calls. Exam-
ples include ones to establish a connection to a web server, to send or
receive packets over the network, to create or delete files, to read or write
data into files, and to create a new user process. To the user program,
these are called just like normal procedures, with parameters and return
values. Like any good abstraction, the caller only needs to be concerned
with the interface; they do not need to know that the routine is actually
being implemented by the kernel rather than by a library. The kernel
handles all of the details of checking and copying arguments, performing
the operation, and copying any return values back into the process's mem-
ory. When the kernel is done with the system call, it resumes user-level
execution at the instruction immediately after the trap.
