User Mode Execution
Computer Architecture - Overview
processor architecture
able to use all of the “normal” instructions
–
privileged execution modes
–
load and store general registers from/to memory
–
asynchronous exceptions (traps)
–
arithmetic, logical, test, compare, data copying
–
branches and subroutine calls
I/O architecture
able to address some subset of memory
–
busses, controllers, devices, smart controllers
–
I/O: direct, polled, mapped, DMA, interrupt driven
–
sequential and random access devices
–
disks and factors affecting disk I/O performance
–
I/O operations, update the MMU
You need to understand how these really work
–
interrupt enables, enter supervisor mode
computer and I/O architecture
–
what is controlled by a Memory Management Unit
not able to perform privileged operations
3/5/03 - 1
computer and I/O architecture
Supervisor Mode Execution
Processor Status Register
can execute privileged instructions
contains condition codes
–
able to perform I/O operations
–
set by arithmetic/logical operations (0,+,-,ovflo)
–
interrupt enable/disable/return, load PS
–
tested by conditional branch instructions
–
instructions to change processor mode
controls execution mode (user/supervisor)
can access privileged address spaces
–
access data structures inside the OS
–
access other process's address spaces
–
change and create address spaces
describes which interrupts are enabled
may describe what address space to use
may control other processor features/options
may have alternate registers, alternate stack
computer and I/O architecture
3/5/03 - 2
3/5/03 - 3
–
word length, endian-ness, instruction set, ...
computer and I/O architecture
3/5/03 - 4
Choice of Execution Modes
Asynchronous Exceptions and Handlers
computer boots up in supervisor mode
–
most errors can be handled “in-line”
used by bootstrap and OS to initialize the system
applications run in user mode
–
OS changes to user mode before running user code
user programs cannot do I/O, restricted address space
–
they have no way to get into supervisor mode
because instructions to change the PS are privileged
reentering supervisor mode is strictly controlled
–
only happens in response to traps and interrupts
computer and I/O architecture
3/5/03 - 5
Trap Handling
st
1 level trap handler
(saves registers and
selects 2nd level handler)
PS/PC
PS/PC
PS/PC
PS/PC
PS/PC
TRAP vector table
return to
user mode
2nd level handler
(actually deals
with the problem)
computer and I/O architecture
–
program can test for, and handle such conditions
some errors must interrupt program execution
–
e.g. CPU was unable to execute this instruction
–
there must be a way to inform OS if this happens
most computers accomplish this with “traps”
–
a well specified list of all possible exceptions
–
a means for the OS to associate handlers with each
computer and I/O architecture
3/5/03 - 6
hardware trap handling
... instr; instr; instr; bad instr; instr; instr; instr ...
supervisor mode
arithmetic overflows are reflected in condition codes
(Transition into Supervisor Mode)
Application Program
user mode
–
3/5/03 - 7
–
use trap cause to index into trap vector table for PC/PS
–
load new processor status word, switch to supv mode
–
push PC/PS of program that caused trap onto stack
–
load new program counter (w/addr of 1st level handler)
software trap handling
–
1st level handler pushes all other registers onto stack
–
1st level handler gathers info, selects 2nd level handler
–
2nd level handler deals with the exception condition
computer and I/O architecture
3/5/03 - 8
Control of Supervisor mode transitions
all user->supervisor changes are via traps/interrupts
–
it is difficult to know when these will happen
there is a designated handler for each trap/intr
–
its address is stored in a trap/interrupt vector table
–
the operating system sets up all of the handler vectors
ordinary programs can't access these vectors
–
vectors are not in the process' address spaces
by carefully controlling all of the trap/intr “gateways”
computer and I/O architecture
some exceptions are handled by the OS
–
e.g. page faults, alignment, floating point emulation
–
OS simulates expected behavior and returns
some exceptions may be fatal to running task
–
e.g. zero divide, illegal instruction, invalid address
–
OS reflects the failure back to the running process
some exceptions may be fatal to the system
the OS controlls all supervisor mode transitions
–
Dealing with the cause of a trap
3/5/03 - 9
–
e.g. power failure, cache parity, stack violation
–
OS cleanly shuts down the affected hardware
computer and I/O architecture
(Returning to User Mode)
Stacking and unstacking a trap
user mode
computation
return is opposite of interrupt/trap entry
supervisor mode stack
user mode stack
growth
user-mode
PC and PS
saved
user-mode
registers
parameters
to 2 nd level
handler
–
2nd level system call handler returns to 1st level handler
–
1st level handler restores all registers from stack
–
use privileged return instruction to restore PC/PS
–
resume user-mode execution after trapped instruction
saved registers can be changed before return
return PC
stack frame
for 2 nd level
handler
...
computer and I/O architecture
3/5/03 - 10
3/5/03 - 11
–
used to set entry point for newly loaded programs
–
used to deliver signals to user-mode processes
–
used to set return codes from system calls
computer and I/O architecture
3/5/03 - 12
Traps while in Supervisor Mode
I/O architectures: busses
nearly identical to traps while in user mode
–
trap saves interrupted PC/PS on supervisor mode stack
–
trap goes to same vector & 1st level handler
–
same register saving, restoring, and return
there are very few differences
control
data
address
interrupts
main bus
–
saved PS at time of interrupt shows supervisor mode
–
2nd level handler knows trap was from supervisor mode
(and may consider it to be more or less severe than the
same trap from user mode)
computer and I/O architecture
Controller
CPU
3/5/03 - 13
Memory
Controller
Device
computer and I/O architecture
Memory type busses
3/5/03 - 14
Network type busses
came from back-plane memory-to-CPU interconnects
evolved as peripheral device interconnects
–
a few “bus masters”, and many “slave devices”
–
SCSI, USB, 1394 (firewire), Infiniband, ...
–
arbitrated multi-cycle bus transactions
–
cables and connectors rather than back-planes
request, grant, address, respond, transfer, ack
–
designed for easy and dynamic extensibility
operations: read, write, read/modify/write, interrupt
–
originally slower than back-plane, but no longer
originally most busses were of this sort
much more similar to a general purpose network
–
ISA, EISA, PCMCIA, PCI, cPCI, video busses, ...
–
distinguished by form-factor, speed, data width, ...
–
newer busses support bridging, hot-swap, self-identifying
computer and I/O architecture
3/5/03 - 15
–
packet switched, topology, routing, node identity
–
may be master/slave (USB) or peer-to-peer (1394)
–
may be implemented by controller or by host
computer and I/O architecture
3/5/03 - 16
I/O architectures: devices & controllers
mechanisms: device controller registers
I/O devices
device controllers export registers to the bus
–
peripheral devices that interface between the computer
and other media (disks, tapes, networks, serial ports,
keyboards, displays, pointing devices, etc.)
device controllers connect a device to a bus
–
communicate control operations to device
–
relay status information back to the bus
–
manage DMA transfers for the device
–
generate interrupts for the device
FER
DCD
PER
RI
reading from registers obtains data/status
may require special instructions (e.g. x86 IN/OUT)
may be mapped onto bus like memory
accessed with normal (load/store) instructions
I/O address space not accessible to most processes
computer and I/O architecture
3/5/03 - 18
(16550 UART registers)
Register
Data Register
Interrupt Enable Register
Interrupt Register
Line Control Register
RTS Modem Control Register
RER Line Status Register
CTS Modem Status Register
A 16550 presents seven 8-bit registers to the bus.
0: data – read received byte, write to transmit a byte
(or LSB of speed divisor when speed set is enabled)
1: interrupt enables – for transmit done, data received, cd/ring
(or MSB of speed divisor when speed set is enabled)
2: interrupt registers – currently pending interrupt conditions
3: line control register – character length, parity and speed
4: modem control register – control signals sent by computer
All communication between the bus and the device (send data,
receive data, status and control) is performed by reading from,
and writing to these registers.
computer and I/O architecture
–
privileged instructions restricted to supervisor mode
A simple device: 16550 UART
BRK
writing into registers controls device or sends data
–
3/5/03 - 17
DTR
OVR
DSR
–
–
computer and I/O architecture
contents
x
x
x
x
x
MDM STS XMT RCV
MDM STS XMT RCV
PARITY
STOP WORDLEN
registers in controller can be addressed from bus
register access method varies with CPU type
a controller is usually specific to a device and a bus
offset
0
x
x
x
1
2
3
spee BRK
d
4
5
RCV EMT XMT
6
–
3/5/03 - 19
5: line status register – xmt/rcv completion and error conditions
6: modem status registers – received modem control signals
computer and I/O architecture
3/5/03 - 20
Scenario: direct I/O with polling
(mechanisms: direct polled I/O)
all transfers happen under direct control of CPU
uart_write_char( char c ) {
while( (inb(UART_LSR) & TR_DONE) == 0);
outb( UART_DATA, c );
}
–
CPU transfers data to/from device controller registers
–
transfers are typically one byte or word at a time
–
may be accomplished with normal or I/O instructions
CPU polls device until it is ready for data transfer
char uart_read_char() {
while( (inb(UART_LSR) & RX_READY) == 0);
return( inb(UART_DATA) );
–
received data is available to be read
–
previously initiated write operations have been completed
advantages
–
}
computer and I/O architecture
3/5/03 - 21
performance of direct I/O
each byte or word transferred requires mutiple instructions
busy-wait polling ties up CPU until I/O is completed
devices are idle while we are running other tasks
–
3/5/03 - 22
bus facilitates data flow in all directions between
CPU is wasted while awaiting completion of transfers
–
computer and I/O architecture
Direct Memory Access – I/O w/o the CPU
CPU intensive data transfers
–
very easy to implement (both hardware and software)
–
CPU, memory, and device controllers
CPU can be the bus-master
–
initiating data transfers with memory or device controllers
device controllers can also master the bus
I/O can only happen when an I/O task is running
–
how can problems be dealt with
CPU instructs controller what transfer is desired
what data to move to/from what part of memory
–
let controller transfer data without attention from CPU
–
device controller performs transfer w/o CPU assistance
–
let application block pending I/O completion
–
device controller generates interrupt at end of transfer
–
let controller interrupt CPU when I/O is finally done
computer and I/O architecture
3/5/03 - 23
computer and I/O architecture
3/5/03 - 24
completion interrupts – waking up CPU
Interrupt Handling
Application Program
device controllers, busses, and interrupts
... instr; instr; instr; instr; instr; instr ...
busses have ability to send interrupts to the CPU
user mode
–
devices signal controller when they are done/ready
supervisor mode
–
when device is done, controller asserts interrupt on bus
CPUs and interrupts
–
1st level
interrupt handler
interrupts look very much like traps
PS/PC
PS/PC
PS/PC
PS/PC
return to
user mode
PS/PC
Interrupt vector table
traps come from CPU, interrupts are caused externally
–
unlike traps, interrupts can be selectively enabled/disabled
2nd level handler
(device driver
interrupt routine)
a device can be told it can or cannot generate interrupts
special instructions can enable/disable interrupts to CPU
computer and I/O architecture
3/5/03 - 25
interrupts vs. traps
–
they are triggered when something happens
–
there is (usually) no persistent state that must be cleared
interrupts are caused a device being in some state
–
they are triggered when the device enters a particular state
–
they will continue to be asserted until device state changes
lock(devlock);
/* lock device */
/* update data read count */
/* program the DMA request */
req_xfr = req_cnt – dp->cnt;
dp->loc = req_loc;
dp->adr = req_adr;
dp->cnt = req_cnt;
dp->op = READ;
/* turn off device ability to interrupt */
dp->ctrl = IDISABLE;
dp->ctrl = IENABLE | GO;
/* wake up the requester */
wakeup(devcompletion);
intr_enable( save );
once delivered, an interrupt must be disabled
await(devcompletion);
/* tell intr dispatcher we're done */
CPU must ignore continuing request for that interrupt
/* request has completed */
cause must be cleared, and interrupt acknowledged
unlock(devlock);
computer and I/O architecture
dev_intr_handler() {
save = intr_enable(DISABLE);
/* re-enable and await completion */
the device is changed from DONE to BUSY again
–
3/5/03 - 26
DMA read w/completion interrupts
traps are caused by an instantaneous condition
–
list of device interrupt handlers
computer and I/O architecture
3/5/03 - 27
/* release device */
computer and I/O architecture
return( ACKNOWLEDGE_INTERUPT)
}
3/5/03 - 28
(device I/O with completion interrupts)
mechanisms: memory mapped I/O
requesting process checks to see if device is busy
DMA may not be the easiest way to do I/O
–
if idle, start the I/O operation, and await its completion
–
if busy, wait for the device to become idle
I/O interrupt handler
–
gathers completion information from the device
–
posts completion awakening requester
wake up the next requester
–
continuous updates to isolated areas of the screen
–
1MB display controller sits on the CPU memory bus
–
each byte of display memory corresponds to one pixel
–
application uses ordinary stores to update display
low overhead per update, no interrupts to service
we'll talk about waiting and waking up in two weeks
computer and I/O architecture
consider a video game display adaptor
implement as a bit-mapped display adaptor
when current device owner finishes using the device
–
–
3/5/03 - 29
relatively easy to program
computer and I/O architecture
trade-off: memory mapped vs. DMA
3/5/03 - 30
Smart Device Controller
DMA performs large transfers efficiently
–
better utilization of both the devices and the CPU
I/O completion interrupts
device doesn't have to wait for CPU to do transfers
–
I/O instructions
but there is considerable per transfer overhead
setting up the operation, processing completion interrupt
memory-mapped I/O has no start/finish overhead
–
device
driver
basic status
basic control
accessed through bus
control registers (on bus)
buffer
pointers
device
controller
but every byte is transferred by a CPU instruction
normal
instructions
DMA better for occasional large transfers
accessed through DMA
memory-mapped better frequent small transfers
memory-mapped devices are more difficult to share
computer and I/O architecture
3/5/03 - 31
shared buffers (in memory)
computer and I/O architecture
3/5/03 - 32
Random v.s. Sequential Access
(I/O Mechanisms: smart controllers)
Smarter controlers can improve on basic DMA
they can queue multiple input/output requests
–
when one finishes, automatically start next one
–
reduce completion/start-up delays
–
eliminate need for CPU to service interrupts
request scheduling to improve perormance
–
they can do automatic error handling & retries
they can better hide the details of underlying devices
computer and I/O architecture
–
byte/block N must be read before byte/block N+1
–
may be read/write once, or may be rewindable
–
examples: magnetic tape, printer, keyboard
Random access devices
they can relieve CPU of other I/O responsibilities
–
Sequential access devices
3/5/03 - 33
–
possible to seek directly to any desired byte/block
–
seeks may or may not be instantaneous
–
examples: memory, magnetic disk, CD, graphics adaptor
They are used very differently
computer and I/O architecture
random access devices: disks
Disk drive geometry
random access devices are much more interesting
–
usage, performance, and scheduling techniques
program loading, file I/O, paging
–
disk performance drives timesharing performance
–
a mounted assembly of circular platters
–
read/write head per surface, all moving in unison
track
–
ring of data readable by one head in one position
cylinder
disk I/O operations are subject to overhead
–
–
higher overhead means fewer operations/second
–
careful scheduling can reduce overhead
–
clever scheduling can improve throughput and delay
computer and I/O architecture
spindle
head assembly
key time sharing services depend on disk I/O
–
3/5/03 - 34
corresponding tracks on all platter
sector
–
3/5/03 - 35
logical records written within tracks
disk address = <cylinder / head / sector >
computer and I/O architecture
3/5/03 - 36
Disk Drive - Logical
Disk Drive – Physical
Sectors
Spindle
Track
10 heads
platter/surface
0
1
5 platters
10 surfaces
head
positioning
assembly
8
9
Cylinder
Motor
computer and I/O architecture
3/5/03 - 37
computer and I/O architecture
Optimizing disk performance
Disk Drive Performance
heads
10
platters
cylinders
17,000
tracks/inch
sectors/track
400
bytes/sector
RPM
7200
speed
seek time
2-15ms (average 9ms)
latency
0-8ms (average 4ms)
best case
worst case
average
don't start I/O until disk is on-cyl/near sector
5
18,000
512
200Mb/sec
–
I/O ties up the controller, locking out other operations
–
other drives seek while one drive is doing I/O
minimize head motion
time to read one 8,000 byte block
seek
rotate
transfer
total
400 s
0ms
0ms
400 s
23.4ms (58X)
15ms
8ms
400 s
13.4ms (33X)
9ms
4ms
400 s
computer and I/O architecture
3/5/03 - 38
–
do all possible reads in current cylinder before moving
–
make minimum number of trips in small increments
encourage efficient data requests
3/5/03 - 39
–
have lots of requests to choose from
–
encourage cylinder locality
–
encourage largest possible block sizes
computer and I/O architecture
3/5/03 - 40
Head Travel under various algorithms
read sections 6-6.3
76
First Come First Served
124 17
269 201 29
137
12
48
107
252
125
Tot=880
29
Shortest Seek First
17
12
124 137
68
172
108
For the next lecture
(see Greek to English dictionary regarding figure 6-3)
there will be a quiz on the reading
76
47
12
5
112
13
64
201
68
topics for the next lecture
269
Tot=321
76
Scan/look (elevator algorithm)
124 137 201 269 29
17
12
48
13
5
Tot=450
64
68
240
12
computer and I/O architecture
3/5/03 - 41
key points
user view of processes
–
process address spaces
–
object modules, load modules, linkage editing
–
procedure calls, stack frames, system calls, signals
computer and I/O architecture
trap and interrupt handling
channels sit between CPU and I/O devices
–
save/restore, vectoring 1st and 2nd level handlers
think of them as extremely smart busses
the include highly specialized CPUs
busses, devices, controllers, interconnections
–
they execute channel I/O programs
I/O mechanisms, what they are, how they work
–
instructions to read, write and control devices
–
instructions to generate progress interrupts
–
polled I/O, direct I/O, memory mapped I/O, DMA
–
interrupt driven I/O, smart controllers
once started, I/O programs execute w/o CPU attention
random access devices
–
disk geometry, disk performance, disk scheduling
computer and I/O architecture
3/5/03 - 42
Channel Controllers – I/O co-processors
supervisor mode execution, privileged instructions
–
–
3/5/03 - 43
–
command chaining
–
data chaining
computer and I/O architecture
3/5/03 - 44
Typical Channel Architecture
Typical Channel Program
(both programs located in main memory)
Device
Controller
0x11?
CPU
Main bus
Channel
Controller
0x1??
Channel
Controller
0x2??
...
Device
Controller
0x1F?
Device
0x110
...
Device
0x11F
SIO 0x101, iopgm
...
...
...
3/5/03 - 45
Channel Controller
iopgm SEEK cyl=1020, hd=5, rec=10
READ buf=xxx, cnt=4096
READX buf=yyy, cnt=4096, intr
TIC
next
next
intr: TIO 0x101
all channels, controllers and devices have "Geographic" addresses
computer and I/O architecture
Main CPU
...
computer and I/O architecture
SEEK cyl=1050, hd=0, rec=2
WRITE buf=zzz, cnt=8192, intr
END
intr
(note, channel can concurrently execute
one program per controller)
3/5/03 - 46