Device Management Gary Nutt Operating Systems Chapter 5 3rd Edition

1
Device ManagementGary NuttOperating
SystemsChapter 5 (3rd Edition)

2
Issue

• i/o devices run several orders of magnitude more
  slowly than CPU
• How to control them so that CPU is maximized.

3
(No Transcript)
4
Direct i/o with polling

• Application does read
• Driver queries controller to see if its busy
• Driver stores command in controller
• Driver repeatedly reads status register while
  waiting for device to complete
• Driver copies contents of controller to user
  memory
• Write is the opposite

5
Problem

• CPU (through the driver) continually checks the
  state of the controller
• Fine for a single process
• Not so fine if other processes are waiting for
  the CPU

6
Solution

• Interrupts
• Much more complex but achieves better average CPU
  use than polling

7
(No Transcript)
8
Interrupt Steps

• Application requests read
• Driver queries status of the controller
• Driver stores command in controllers register
• Driver stores information about this request in
  the slot of the device table associated with the
  device (e.g., the return address and parameters).
  Device manager invokes scheduler so that cpu can
  run another process
• Device completes, interrupts the CPU. Causes the
  interrupt handler to run.
• Interrupt handler determines which device caused
  interrupt. Branches to the handler for that
  device.
• Handler retrieves pending i/o info from the
  device status table
• Device handler copies controllers data registers
  into user memory
• Device handler returns control to application
  process.
• From the point of view of the application
  process, this is serialized. From the point of
  view of the O/S, several of these operations
  could be pending since the process blocks until
  i/o completes

9
Memory-Mapped i/o

• Instead of conceiving of the device and memory as
  different addresses, think of them as continuous.
• Transparency
• DMA controllers are able to read and write data
  directly from/to primary memory addresses with no
  CPU intervention after driver has initiated i/o
  request.

10
(No Transcript)
11
Double Buffering

• Suppose you send a job to a printer locally
  connected
• Can you stop it?
• No, because the printer maintains its own memory
  where the job is stored
• Other devices work in this way, too.

12
Multiple Buffers

• Suppose we have an i/o bound process
• Reads a sequence of bytes from a modem
• Device could maintain two buffers
• One being written to (even when the program has
  not called the next read op)
• One being read from
• The overlap will be well-matched if the amount of
  time necessary to read the next character is the
  amount of time the process requires before it
  requires the next
• This could be pushed a level further by buffering
  at the controller level too

13
(No Transcript)
14
This the Producer/Consumer Problem

• Producer ? Controller
• Consumer ? Process
• Two problems
• Consumer gets ahead of the producer?blocks
• Producer gets ahead of the consumer?blocks or
  buffer overflow

15

• Buffering works best when a process alternates
  between being compute and i/o bound
• Compute bound? buffer fills
• i/o bound? process empties buffers

16
Janus?

• Roman god of gates and doors
• Metaphor for device driver
• 1 face looks at the user program through the API,
  the o/s interface
• 1 face looks at device controller

17
API

• Unix tries to make i/o functions as general as
  possible
• Read
• Close
• Open
• Write

18
Linux I/O Ops
19
But there are differences

• Some storage devices are sequential
• Some are random access
• Some have peculiar physical characteristics
• Is the disk spinning?
• Is the tape rewound?
• Is the video image inverted?

20
Kernel Interface

• Driver, since it accesses the address space of
  different processes, must run in kernel mode.
• Solution Make the driver part of the o/s.
  Recompile o/s when you change drivers?minix

21
Open systems approach demands more flexibility

• Process gets to a driver by accessing an indirect
  reference table. Change the driver, change
  address in the table
• Example?/dev/had, /dev/fd0

22
Three Device Management Scenarios

• Serial?character
• Sequential?block
• Random?block

23
Serial

• Driver manipulates the controller
• Controller manipulates the device using a
  pre-defined protocol (e.g., RS-232) that
  specifies
• Physical nature of the cabling that connects
  controller and device
• Expected signals

24
Sequential

• Block as opposed to character
• Tape is the only real example
• Bytes collected together to form a physical
  record called a block
• Blocks are separated by inter-record gap
• Each read processes an entire block
• Tapes are characterized by physical density 6250
  bpi is typical
• Seek is very slow?sequential access only

25
Random

• Disk Pack
• Units tracks/cylinder/sectors
• Issues
• Seek time (find the proper track)
• Rotational delay (find proper sector)
• Block transfer rate

26
How to Minimize Seek Time

• First come first served
• Shortest seek time first
• Scan
• Scans all tracks in order, servicing all requests
  for a track when it passes it. Reverse direction
  when r/w head gets to the highest track
• Circular Scan
• Instead of reversing direction, start over at
  Track 0, because if request for track 1 came in
  after track 1, 1 would have to wait for almost
  two full scans to be serviced.