Successfully reported this slideshow.
I/O
Beuth Hochschule

Summer Term 2014

!
Pictures (C) W. Stallings, if not stated otherwise

!
Additional source:

Daniel...
Operating Systems I PT/FF 14
Input / Output Devices
• Hardware devices engaged in I/O can be categorized into:

• Responsi...
Operating Systems I PT/FF 14
I/O Functionality
• I/O functionality in an operating system can take place as:

• Programmed...
Operating Systems I PT/FF 14
I/O Hardware - Single Bus
4
(C) Russinovich et al.
Operating Systems I PT/FF 14
I/O Hardware - Multiple Busses
5
(C) Russinovich et al.
Operating Systems I PT/FF 14
Direct Memory Access (DMA)
• Special hardware unit realizes the
data transfer between device ...
Operating Systems I PT/FF 14
Device Drivers
• Lowest level of software to interact with I/O hardware

• Contains all devic...
Operating Systems I PT/FF 14
Flow of a Blocking I/O Request
1. Thread issues blocking read() system call

2. Kernel checks...
Operating Systems I PT/FF 14
Design Objectives
• Design objectives for the I/O mechanism in
operating systems

• Generalit...
Operating Systems I PT/FF 14
Layers of the I/O System
• Device-independent software layer
combines common management tasks...
Operating Systems I PT/FF 14
Buffering
• Typical optimization is buffering of I/O requests
• Perform input transfers in adv...
Operating Systems I PT/FF 14
Buffering
• No buffer - Operating system directly accesses the device

• Single buffer - Operat...
Operating Systems I PT/FF 14
Windows
• I/O system design goals

• Fast I/O processing on single / multiprocessor systems

...
Operating Systems I PT/FF 14
Windows
14
(C) Russinovich et al.
Operating Systems I PT/FF 14
Windows - I/O Architecture
• I/O Manager 

• Connects applications and components to virtual,...
Operating Systems I PT/FF 14
Windows - I/O Architecture
• The hardware abstraction layer (HAL) insulates drivers from the ...
Operating Systems I PT/FF 14
Driver Layering
• Windows drivers can be stacked
to add functionality

• Only the lowest laye...
Operating Systems I PT/FF 14
Windows - IRPs
• I/O manager creates an IRP for each I/O operation and passes it to correct d...
Operating Systems I PT/FF 14
Windows - Interrupt Dispatching
19
(C) Russinovich et al.
Operating Systems I PT/FF 14
Windows - Interrupt Dispatching
• IRQL is the state of a processor in the system

• Servicing...
Operating Systems I PT/FF 14
Windows - IRQLs
• High - Used when halting the system (via KeBugCheck())

• Power fail - Orig...
Upcoming SlideShare
Loading in …5
×

Operating Systems 1 (11/12) - Input / Output

2,514 views

Published on

A short introduction into the principles of input / output and device management in modern operating systems.

Published in: Education
  • Be the first to comment

Operating Systems 1 (11/12) - Input / Output

  1. 1. I/O Beuth Hochschule Summer Term 2014 ! Pictures (C) W. Stallings, if not stated otherwise ! Additional source: Daniel P. Bovet & Marco Cesati. Understanding the Linux Kernel. 3rd Edition. O‘Reilly ! ! !
  2. 2. Operating Systems I PT/FF 14 Input / Output Devices • Hardware devices engaged in I/O can be categorized into: • Responsible for interaction with the user • Printers, terminals, video display, keyboard, mouse • Provisioning of system-local hardware functionality • Disk drives, USB keys, sensors, controllers • Provisioning of communication support • Modems, WLAN stick, network card • Devices differ according to multiple factors • Data transfer rates, complexity of control, data encoding, error conditions, ... • I/O devices either operate as block device (fixed-size data blocks) or 
 character / stream device (stream of bytes) 2
  3. 3. Operating Systems I PT/FF 14 I/O Functionality • I/O functionality in an operating system can take place as: • Programmed I/O with polling • Process issues I/O command indirectly through the operating system • Busy waits for completion • Interrupt-driven I/O • Process issues I/O command indirectly through the operating system • Operating system blocks the process until an interrupt signals I/O completion • With non-blocking I/O, the process continues to work instead of being blocked • In both cases, the processor must fetch I/O read results from the device • Alternative: Direct Memory Access (DMA) 3
  4. 4. Operating Systems I PT/FF 14 I/O Hardware - Single Bus 4 (C) Russinovich et al.
  5. 5. Operating Systems I PT/FF 14 I/O Hardware - Multiple Busses 5 (C) Russinovich et al.
  6. 6. Operating Systems I PT/FF 14 Direct Memory Access (DMA) • Special hardware unit realizes the data transfer between device and main memory 6
  7. 7. Operating Systems I PT/FF 14 Device Drivers • Lowest level of software to interact with I/O hardware • Contains all device-dependent code for one type of hardware unit • Direct communication with the device hardware • Writes control registers, accesses hardware-mapped memory regions • Starting and completion of I/O operations • Loaded drivers become part of the running operating system image • User mode applications deal with logical I/O • Processes are enabled to access data records in files • Driver may block after issuing a request, un-blocked by device interrupt 7
  8. 8. Operating Systems I PT/FF 14 Flow of a Blocking I/O Request 1. Thread issues blocking read() system call 2. Kernel checks parameters, may already return buffered data and finish 3. Thread is suspended if physical I/O required, added to wait queue for device 4. I/O request is scheduled 5. Device driver allocates kernel buffer and sends command to the hardware controller 6. Device controller operates the hardware to perform data transfer 7. Driver may poll for status and data, or set up DMA that will generate interrupt 8. Interrupt occurs, handler implementation from the driver stores the data 9. Kernel transfers data to user space and makes thread ready again 10. Thread resumes execution at completion of read() call 8
  9. 9. Operating Systems I PT/FF 14 Design Objectives • Design objectives for the I/O mechanism in operating systems • Generality • Handle all devices in a uniform manner, 
 both for kernel and user mode • Hierarchical approach for device management to reflect bus topology • Efficiency • I/O operations nearly always are the main bottleneck in application performance • Most I/O devices are extremely slow compared with main memory and processor • Operating system must take care of disk I/O coordination and performance 9
  10. 10. Operating Systems I PT/FF 14 Layers of the I/O System • Device-independent software layer combines common management tasks • Uniform interfacing for device interaction (e.g. read / write / create) • Device naming • Device protection • Buffering • Storage allocation on block devices • Allocation and releasing • Error reporting 10 User process Device-independent software layer Device driver layer Interrupt handlers Hardware
  11. 11. Operating Systems I PT/FF 14 Buffering • Typical optimization is buffering of I/O requests • Perform input transfers in advance of requests being made • Perform output transfers delayed, after the request is made 11
  12. 12. Operating Systems I PT/FF 14 Buffering • No buffer - Operating system directly accesses the device • Single buffer - Operating system assigns buffer in main memory for I/O request • For block-oriented devices, read-ahead may manage to prepare blocks in memory that are fetched later by the process • For stream-oriented devices, read-ahead is based on the notion of text lines (terminals) or bytes (terminals, video stream) • Swapping logic of the operating system is affected • Double buffer / buffer swapping - Process can transfer data from / to one buffer while the operating system empties or fills the other buffer • Circular buffer - Two or more buffers are used in a circular fashion • Buffering smoothes out peaks in I/O demand, less advantage under heavy load 12
  13. 13. Operating Systems I PT/FF 14 Windows • I/O system design goals • Fast I/O processing on single / multiprocessor systems • Protection for shareable resources using Windows security mechanisms • Meet requirements dictated by different subsystems • Provide common services for device drivers • Ease device driver development, support for high-level languages • Dynamic addition/removal of device drivers • Support multiple file systems (FAT, CDFS, UDF, NTFS) • Provide mapped file I/O capabilities • Instrumentation support and diagnosability 13
  14. 14. Operating Systems I PT/FF 14 Windows 14 (C) Russinovich et al.
  15. 15. Operating Systems I PT/FF 14 Windows - I/O Architecture • I/O Manager • Connects applications and components to virtual, logical, and physical devices • Windows APIs: ReadFile, WriteFile, CreateFile, CloseFile, DeviceIoControl • Defines the infrastructure that supports device drivers • Manages buffers for I/O requests • Provides time-out support for drivers • Knows which installable file systems are loaded • Provides flexible I/O services for environment subsystems • Framework for delivery of I/O request packets (IRPs) 15
  16. 16. Operating Systems I PT/FF 14 Windows - I/O Architecture • The hardware abstraction layer (HAL) insulates drivers from the specifics of processor and interrupt controller • Bus driver for all the devices on the computer's motherboard that aren't controlled by other drivers • By programming against the HAL, drivers are source-level compatible across different CPU and mainboard architectures • PnP manager handles driver loading and starting • Performs resource arbitration • Relies on the I/O Manager to manage drivers and send PnP-related commands • Power manager controls the power states • Relies on the I/O Manager to ask drivers if they can change power state 16
  17. 17. Operating Systems I PT/FF 14 Driver Layering • Windows drivers can be stacked to add functionality • Only the lowest layer talks to the hardware • Filter drivers attach their devices to other devices • See‘s all requests first an can manipulate them • Examples: File replication, file encryption, shadow copies, licensing, virus scanner 17
  18. 18. Operating Systems I PT/FF 14 Windows - IRPs • I/O manager creates an IRP for each I/O operation and passes it to correct drivers • Deletes IRP when I/O operation is complete • Device drivers • Receive IRP routed to them by the I/O manager and performs the operation • Inform the I/O manager when those commands complete by passing back the IRP • Often use the I/O manager to forward IRPs to other device drivers • Fast I/O • Bypass generation of IRPs, go directly to file system driver or cache manager • Scatter/Gather I/O • Read/write multiple buffers with a single system call 18
  19. 19. Operating Systems I PT/FF 14 Windows - Interrupt Dispatching 19 (C) Russinovich et al.
  20. 20. Operating Systems I PT/FF 14 Windows - Interrupt Dispatching • IRQL is the state of a processor in the system • Servicing an interrupt raises the processor IRQL to that interrupt‘s IRQL • This masks subsequent interrupts with an equal or lower IRQL • User mode 
 applications are 
 limited to IRQL 0 • No wait operations 
 or page faults for 
 IRQL >= 2 • After ISR execution,
 IRQL is lowered to
 initial level 20 Passive/Low APC Dispatch/DPC Device 1 . . . Profile & Synch (Srv 2003) Clock Interprocessor Interrupt Power fail High Normal thread execution Hardware interrupts Deferrable software interrupts 0 1 2 30 29 28 31
  21. 21. Operating Systems I PT/FF 14 Windows - IRQLs • High - Used when halting the system (via KeBugCheck()) • Power fail - Originated in the NT design document, but has never been used • Inter-processor interrupt - used to request action from other processor (dispatching a thread, updating a processors TLB, system shutdown, system crash) • Clock - Used to update system‘s clock, allocation of CPU time to threads • Profile - Used for kernel profiling (see Kernel profiler – Kernprof.exe, Res Kit) • Device - Used to prioritize device interrupts • DPC/dispatch and APC - Software interrupts 
 that kernel and device drivers generate • Passive - No interrupt level at all, 0
 normal thread execution 21 Passive/Low APC Dispatch/DPC Device 1 . . . Profile & Synch (Srv 2003) Clock Interprocessor Interrupt Power fail High Normal thread execution Hardware interrupts Deferrable software interrupts 0 1 2 30 29 28 31

×