Outline
•
•
•
•
Announcements
Computer Architecture – continued
Signal handling in Unix
Device Management
– Device Drivers
– I/O Strategies
– Polling vs. interrupt-driven I/O
Announcements
• We are going to have a quiz at the end of the
class on Sept. 18, 2003
– Which is a week from today
– It will be a closed book and closed notes quiz
– It will cover
• System calls and how to use them
• Lecture notes up to next Tuesday (Sept. 16)
• Related materials in the book
5/29/2016
COP4610
2
Announcements – cont.
• Next week’s recitation session (Sep. 17) will
be optional
– I will use that mainly to answer questions related
to the first programming assignment
• By today we should have covered everything you
need to know in order to implement the assignment
– You are not required to attend as I will not cover
new materials
– I will be in LOV 301 as we normally meet for
recitation
5/29/2016
COP4610
3
Announcements – cont.
• Comments regarding the first programming
assignment
– You can use simple-shell.cc as a starting point or
the code in the textbook
• You can use the code segments from examples I
distributed
• Please note that you are not allowed to copy other’s
work
• Comments on Homework #1
5/29/2016
COP4610
4
Device Drivers
• The part of OS that implements device
management is called collectively as device
manager, which includes device drivers and
device driver infrastructure
– Device drivers can be complex
– However, the drivers for different devices
implement a similar interface so that a higherlevel component has a uniform interface for
different devices
5/29/2016
COP4610
5
Device Driver Interface
…
write(…);
…
Device Interface
5/29/2016
Terminal
Driver
Printer
Driver
Disk
Driver
Terminal
Controller
Printer
Controller
Disk
Controller
COP4610
6
Device Management Organization
Application
Process
System Interface
File
Manager
Device-Independent
Device-Dependent
Hardware Interface
Command
Status
Data
Device Controller
5/29/2016
COP4610
7
I/O Strategies
• Direct I/O
– The CPU is responsible for determining when the
I/O operation has completed and then for
transferring the data between the primary
memory and the device controller data registers
• Polling or interrupt-driven I/O
– This seems not effective for devices with large
transfers, such as a disk drive
• Direct Memory Access (DMA)
5/29/2016
COP4610
8
Direct-Memory Access
• Direct memory access controllers
– Can read/write data directly from/to primary
memory addresses with no CPU intervention
after the driver has started the I/O operation
5/29/2016
COP4610
9
Direct-Memory Access – cont.
5/29/2016
COP4610
10
Direct-Memory Access – cont.
5/29/2016
COP4610
11
I/O Strategies – cont.
• Direct I/O or DMA for data transferring
• Polling or interrupt-driven
• I/O strategies
– Direct I/O with polling
– DMA I/O with polling
• Not supported in general
– Direct I/O with interrupts
– DMA I/O with interrupts
5/29/2016
COP4610
12
Direct I/O with Polling
read(device, …);
1
System Interface
Data
read function
5
write function
2
3
4
Hardware Interface
Command
Status
Data
Device Controller
5/29/2016
COP4610
13
Device Controllers – cont.
...
busy
Command
done
Error code
Status
...
busy done
0
0 idle
0
1 finished
1
0 working
1
1 (undefined)
Data 0
Data 1
Logic
Data n-1
5/29/2016
COP4610
14
Hardware
Software
Polling I/O
…
// Start the device
…
While(busy == 1)
wait();
// Device I/O complete
…
done = 0;
busy
done
…
while((busy == 0) && (done == 1))
wait();
// Do the I/O operation
busy = 1;
…
5/29/2016
COP4610
15
Interrupt-Driven I/O
read(device, …);
1
9
8b
Data
System Interface
Device Status Table
read driver
2
4
7
Device
Handler
write driver
6
3
Interrupt
Handler
8a
5
Hardware Interface
Command
Status
Data
Device Controller
5/29/2016
COP4610
16
Interrupt-Driven Versus Polling
• In general, an interrupt-driven system will
have a higher CPU utilization than a pollingbased system
– The CPU time on polling by one process may be
utilized by another process to perform
computation
5/29/2016
COP4610
17
Comparison of Polling and Interrupt-Driven I/O Performance
• Polling is normally superior from the
viewpoint of a single process
– Because overhand of polling is less
• Interrupt-driven I/O approach gives better
overall system performance
5/29/2016
COP4610
18
I/O-CPU Overlap
Through interrupt-driven I/O
5/29/2016
COP4610
19
I/O-CPU Overlap – cont.
• Sequential operation and overlapped
operation
5/29/2016
COP4610
20
I/O-CPU Overlap – cont.
- I/O-CPU overlap through overlapped operation
and polling
5/29/2016
COP4610
21
I/O-bound and Compute-bound Processes
• I/O-bound process
– A process’s overall execution time is dominated
by the time to perform I/O operations
• Compute-bound process
– A process’s time on I/O is small compared to the
amount of time spent using the CPU
• Many processes have I/O-bound and
compute-bound phases
5/29/2016
COP4610
22
Phases of a Process
Compute-bound
Time
I/O-bound
5/29/2016
COP4610
23
Device Manager Design
• Device drivers
– Application programming interface
– Coordination among application processes,
drivers, and device controllers
– Performance optimization
5/29/2016
COP4610
24
BSD UNIX Driver Functions
5/29/2016
COP4610
25
The Kernel Interface
5/29/2016
COP4610
26
Device-Independent Function Call
funci(…)
Trap Table
5/29/2016
dev_func_i(devID, …) {
// Processing common to all devices
…
switch(devID) {
case dev0:
dev0_func_i(…);
break;
case dev1:
dev1_func_i(…);
break;
…
case devM:
devM_func_i(…);
break;
};
// Processing common to all devices
…
}
COP4610
27
Re-configurable Device Drivers
System call interface
open(){…}
read(){…}
Entry Points for Device j
etc.
Other
Kernel
services
Driver for Device j
5/29/2016
COP4610
28
Handling Interrupts
Device driver J
int read(…) {
// Prepare for I/O
save_state(J);
out dev#
// Done (no return)
}
Device status table
J
Device interrupt handler J
void dev_handler(…) {
get_state(J);
//Cleanup after op
signal(dev[j]);
return_from_sys_call();
}
Interrupt Handler
Device Controller
5/29/2016
COP4610
29
Handling Interrupts – cont.
Device driver J
Device interrupt handler J
int read(…) {
…
out dev#
// Return after interrupt
wait(dev[J});
return_from_sys_call();
}
void dev_handler(…) {
//Cleanup after op
signal(dev[j]);
}
Interrupt Handler
Device Controller
5/29/2016
COP4610
30
CPU-device Interactions
5/29/2016
COP4610
31
Device Management in Linux
• While it builds on the same basic principles,
it is more complex and with more details
– There are a lot of device drivers included and you
can also develop your own device drivers for
specific purpose devices
• Linux divides into char-oriented devices and
block oriented devices
– fs/blk_dev.c
– fs/char_dev.c
5/29/2016
COP4610
32
Buffering
• Buffering
– A technique to keep slower I/O devices busy
during times when a process is not requiring I/O
operations
5/29/2016
COP4610
33
The Pure Cycle Water Company
Customer Office
Water Company
Returning the Empties
Water Producer
Water Consumers
Delivering Water
5/29/2016
COP4610
34
Buffering – cont.
5/29/2016
COP4610
35
Double Buffering
5/29/2016
COP4610
36
Multiple Buffers
- Producer-consumer problem
5/29/2016
COP4610
37
Spooling
• A spool is a buffer that holds output for a
device that cannot accept interleaved data
streams
– Printer is an example
5/29/2016
COP4610
38
Communication Devices
Bus
Generic
Controller
Communications
Controller
Local
Device
Cabling connecting the
controller to the device
Device
•Printer
•Modem
•Network
5/29/2016
COP4610
39
Randomly Accessed Devices
5/29/2016
COP4610
40
Optimizing Access to Rotating Devices
• Access time has three major components
– Seek time – the time for the disk arm to move the
heads to the cylinder containing the desired sector
– Rotational latency – the additional time waiting for
the disk to rotate the desired sector to the disk head
– Transfer Time - time to copy bits from disk surface
to memory
5/29/2016
COP4610
41
Optimizing Seek Time
• Multiprogramming on I/O-bound programs
=> set of processes waiting for disk
• Seek time dominates access time =>
minimize seek time across the set
• Tracks 0:99; Head at track 75, requests for
23, 87, 36, 93, 66
5/29/2016
COP4610
42
Optimizing Access to Rotating Devices
-First-Come-First-Served (75), 66, 87, 93, 36, 23
52+ 64 + 51 + 57 + 27 = 251 steps
5/29/2016
COP4610
43
Optimizing Access to Rotating Devices – cont.
-Shortest-Seek-First-First
- SSTF: (75), 66, 87, 93, 36, 23
–11 + 21 + 6 + 57 + 13 = 107 steps
5/29/2016
COP4610
44
Optimizing Access to Rotating Devices – cont.
-Scan/Look
- Scan: (75), 87, 93, 99, 66, 36, 23
–12 + 6 + 6 + 33 + 30 + 13 = 100 steps
- Look: (75), 87, 93, 66, 36, 23
–12 + 6 + 27 + 30 + 13 = 87 steps
5/29/2016
COP4610
45
Optimizing Access to Rotating Devices – cont.
- Circular Scan/
Circular Look
• Circular Scan: (75), 87, 93, 99, 23, 36, 66
–12 + 6 + 6 + home + 23 + 13 + 30 = 90 + home
• Circular Look: (75), 87, 93, 23, 36, 66
–12 + 6 + home + 23 + 13 + 30 = 84 + home
5/29/2016
COP4610
46
Serial Port
CPU
Memory
Serial
Device
• Printer
• Terminal
• Modem
• Mouse
• etc.
5/29/2016
COP4610
47
Serial Port
Device Driver API
Device Driver
Software on the CPU
• Set UART parms
•read/write ops
•Interrupt hander
UART API
•parity
•bits per byte
•etc.
5/29/2016
COP4610
Bus Interface
Serial Device
(UART)
RS-232 Interface
• 9-pin connector
• 4-wires
• bit transmit/receive
• ...
48
Adding a Modem
CPU
Memory
Serial
Device
Modem
• Dialing & connecting
• Convert analog voice to/from digital
• Convert bytes to/from bit streams
• Transmit/receive protocol
Phone
Switched Telephone Network
5/29/2016
COP4610
49
Serial Communication
Device Driver
•Set UART parms
•read/write ops
•Interrupt hander
Driver-Modem Protocol
• Dialing & connecting
• Convert analog voice to/from digital
• Convert bytes to/from bit streams
• Transmit/receive protocol
5/29/2016
COP4610
Serial Device
RS-232
Modem
50
Exploiting the Phone Network
Logical Communication
CPU
Memory
CPU
Comm
Device
Comm
Device
Modem
Modem
Phone
Phone
Memory
Switched Telephone Network
5/29/2016
COP4610
51
Summary
• Device Management Organization
• I/O Strategies
• Device is the bottleneck for I/O-bound
processes
– Overlap between I/O and CPU will increase the
system’s throughput rate
5/29/2016
COP4610
52