Information Technology Reference
In-Depth Information
Multiprocessors and interrupt routing
On a multiprocessor, which of the various processors should take an interrupt? Some
early multiprocessors dedicated a single processor (“processor 0”) to take all external
interrupts. If an event required a change to what one of the other processors was doing,
processor 0 could send an interprocessor interrupt to trigger that processor to switch to
a new process.
For systems needing to do a large amount of input and output, such as a web server,
directing all I/O through a single processor can become a bottleneck. In modern sys-
tems, interrupt routing is increasingly programmable, under control of the kernel. Often,
each processor has its own, asynchronous, timer, so that different processors take in-
terrupts at different times, reducing contention for shared data structures. Likewise, disk
I/O events can be sent directly to the processor that requested the I/O operation, rather
than to a random processor. Modern multicore systems can run as much as 1000 times
faster if their data is already loaded into the processor cache versus if code and data
needs to be transferred from some other processor.
Efficient delivery of network I/O packets is even more challenging. A high perfor-
mance server might send and receive more than 100,000 packets per second, repre-
senting thousands of different connections. From a processing perspective, it is best
to deliver incoming packets to the processor responsible for handling that connection;
this requires the network interface hardware to demultiplex the incoming packet based
on the contents of its header. Recent network controllers accomplish this by supporting
multiple buffer descriptor rings for the same device, choosing which ring to use, and
therefore which processor to interrupt, based on the arriving packet header.
interrupt stack points to that process's kernel stack. Note that when a process
is running at user-level, it is not running in the kernel so its kernel stack is
empty.
Allocating a kernel stack per process makes it easier to switch to a new
process inside an interrupt or system call handler. For example, when the
timer interrupt handler runs, it might decide to give the processor to a different
process. Likewise, a system call might need to wait for an I/O operation to
complete, and meanwhile we would want to give the processor to someone else.
With per-process stacks, to suspend a process, we simply store a pointer to its
kernel stack in the process control block, and switch to running on the stack of
the new process. We will describe this mechanism in much more detail in the
next chapter,
Figure 2.8 summarizes the various states of a process's user and kernel stacks:
If the process is running on the processor in user-mode, its kernel stack is
empty, ready to be used for an interrupt.
If the process is running on the processor in kernel-mode, e.g., due to
