Object-Oriented Programming
Operating Systems
Lecture 10b
Dr Ronald Grau School of Engineering and Informatics Spring term 2018
Previously
The I/O System
Interaction protocols
Blocking vs. non-blocking I/O
1
Recap questions
1. Which general factors make the I/O system of an operating system complex?
2. How do OS designers cope with this complexity?
3. What can we do with a block device that we cannot with a character device?
4. What are the advantages/disadvantages of
Polling?
Interrupt-driven I/O?
DMA?
5. What is the difference between blocking and non-blocking I/O?
2
Example: Programmed I/O 3
Example: Interrupt-Driven I/O 4
I/O Request Flow 5
I/O Queue 6
I/O Performance Optimisation
Disk operations in disk I/O queue
Reorder requests to optimise
access times?
scheduling
Example: Disk scheduling
First Come First Served (FCFS)
7
Head moves 640 cylinders
minimise head movement
I/O Performance Optimisation
Example: Disk scheduling
Shortest Seek Time First (SSTF)
8
Head moves 236 cylinders
I/O Performance Optimisation
SCAN (elevator) algorithm:
Move head back and forth in one direction
moves head only 208 cylinders
Variants: C-SCAN, LOOK, . . .
NOOP
FCFS, but looks for adjacent requests and merges them
Low overhead
Works well for SSD
Used in Linux
9
Memory-Mapped Files
Shared file access through shared memory
Synchronisation: copy-on-write
Use paging system
10
Memory-Mapped Files 11
Memory-Mapped I/O
Problem: Page replacement
Cannot evict page during an I/O request
locking / pinning
Page caching:
Physical memory written
by DMA or I/O controller:
stale page disable caching of page
HW support
e.g. by page attributes
12
Direct I/O and Memory-Mapped I/O 13
Double buffering Unified buffer cache
I/O System Design 14
Efficiency
I/O is often bottleneck of the system, i.e. CPU has to wait, processes are blocked, . . .
But: I/O devices types have different properties
require specific solutions, i.e. disk scheduling for hard disks vs SSD
Flexibility
Many different devices with different properties,
new devices must be easily supported, . . .
But: uniform programming interface required, e.g. files
uniform interface and device-specific behaviour
I/O System Design 15
I/O system call interface
Provides uniform API (e.g. POSIX system calls)
Hardware-independent
Scheduling and control
I/O queues, buffering, caching, . . .
(Mostly) hardware-independent
Device drivers
Translate operations into device-specific commands
(Mostly) hardware-dependent
I/O System in the Linux Kernel 16
I/O System in the Linux Kernel 17
Uses loadable modules
to install device drivers
Files vs Sockets 18
Summary
System call interface
Uniform abstraction of I/O operations
Blocking vs non-blocking calls
I/O System
Layered structure:
Hardware Abstraction Layer
separating HW-dependent
/-independent
Device driver
I/O controller
19
Interaction protocols
Polling, interrupts, DMA
I/O Scheduling and Optimisations
Reduce blocking times by
reordering requests, e.g. disk scheduling
Buffering, caching, memory-mapped I/O
Read
Tanenbaum & Bos., Modern Operating Systems
Chapter 5
Silberschatz et al., Operating System Concepts
Chapter 10 & 13
20
Next Lecture
Introduction
Operating System Architectures
Processes
Threads – Programming
Process Scheduling – Evaluation
Process Synchronisation
21
Deadlocks
Memory Management
File Systems
Input / Output
Security and Virtualisation