Performance

13.7 Performance ( Optional )

• The I/O system is a major factor in overall system performance, and can place heavy loads on other major components of the system ( interrupt handling, process switching, memory access, bus contention, and CPU load for device drivers just to name a few. )
• Interrupt handling can be relatively expensive ( slow ), which causes programmed I/O to be faster than interrupt-driven I/O when the time spent busy waiting is not excessive.
• Network traffic can also put a heavy load on the system. Consider for example the sequence of events that occur when a single character is typed in a telnet session, as shown in figure 13.15. ( And the fact that a similar set of events must happen in reverse to echo back the character that was typed. ) Sun uses in-kernel threads for the telnet daemon, increasing the supportable number of simultaneous telnet sessions from the hundreds to the thousands.

Figure 13.15 - Intercomputer communications.

• Other systems use front-end processors to off-load some of the work of I/O processing from the CPU. For example a terminal concentrator can multiplex with hundreds of terminals on a single port on a large computer.
• Several principles can be employed to increase the overall efficiency of I/O processing:
  1. Reduce the number of context switches.
  2. Reduce the number of times data must be copied.
  3. Reduce interrupt frequency, using large transfers, buffering, and polling where appropriate.
  4. Increase concurrency using DMA.
  5. Move processing primitives into hardware, allowing their operation to be concurrent with CPU and bus operations.
  6. Balance CPU, memory, bus, and I/O operations, so a bottleneck in one does not idle all the others.
• The development of new I/O algorithms often follows a progression from application level code to on-board hardware implementation, as shown in Figure 13.16. Lower-level implementations are faster and more efficient, but higher-level ones are more flexible and easier to modify. Hardware-level functionality may also be harder for higher-level authorities ( e.g. the kernel ) to control.

Figure 13.16 - Device functionality progression.