I/O Systems

◦Operating Systems◦CS550

Note:

Based on Operating Systems Concepts by Silberschatz, Galvin, and Gagne

Strongly recommended to read Sections 12.8 - 12.10 We may not have time to go over them, but there

might be a question about NFS on the final.

Blocking & Non-Blocking I/O• Blocking - system call suspends application and

moves application to wait queue to wait for system call to complete. Simple and easy to understand. •Non-blocking I/O - example - receive keyboard and mouse input while processing and displaying data on screen. Provided by some operating systems.

-Does not stop application from running for a long period of time.

- Different from MPI non-blocking operations

Asynchronous system callsAsynchronous system calls are another means of providing this• Returns without waiting for I/O to finish • I/O completed by setting a variable, triggering a signal or

causing a SW interrupt • Difference from non-blocking I/O is that nonblocking

returns whatever data is available and asynchronous requests that I/O be completed at a later time. • Often used in modern operating systems Ex: disk and

network I/O• Both buffer I/O and return to the application. • Buffers must be flushed, though • OS usually has a time limit on how long data can stay in

the buffer • OS must also maintain data consistency

Example:o"select" system call for TCP/IP socketsochecks if network I/O is possible by using a wait time of zero as a parameter This is a non-blocking operationo"read()" or "write()" must be used to perform data transfer after calling "select()". These could be blocking, non-blocking, or asynchronous.

Vectored I/O

Allow one system call to perform multiple I/O ops in many locations implemented via "readv" system call, also called "scatter-gather" methods

read accepts a vector of many buffers and is able to read from all at once or write to all at once, sometimes as an atomic operation.

Can occur using vector fields on CPU or via system calls or within libraries (MPI).

Can improve read/write speeds

Kernel I/O Kernel provides I/O scheduling, buffering, spooling,

reservation of devices, and error checks Scheduling has been previously discussed (disk I/O methods

like SSTF, Elevator, etc.) A device status table is used by the kernel to assist with this

scheduling We will discuss many of the other topics with respect to

kernel I/O

I/O Buffers1. Buffer - stores data being transferred between two

devices 2. Done for 3 reasons 3. Speed mismatch between producer and consumer 4. Adapt for device with different transfer sizes 5. To support copy semantics - guarantee of data

consistency between devices

I/O Caching6. Cache - fast memory to hold copies of data 7. Difference between caches and buffers - cache holds a

copy of data on a fast storage device whereas buffer may hold the only existing copy of data.

8. Sometimes memory may be used for both caching and buffering

Spooling

• Spool - a buffer that holds output for a device like a printer • OS takes all data for a device like a printer and holds it in

a spool (e.g. a file) • Once device finishes its job, OS gets next item from the

spool and sends it to the device • Could limit devices to only have one open spool file, if

they cannot multiplex jobs

• OS must protect against HW and application errors when said HW/app fails • OS can compensate sometimes • Ex: on failed "read()" retry "read()" or on failed "send()" issue

"resend()" • System calls typically return an error bit • UNIX/Linux calls return "errno" which may be one of several

hundred error codes • Some HW such as SCSI (pronounced "scuzzy") may provide very

detailed information such as a "sense-key" detailing the nature of the error, an "additional sense code" giving the failure category, and even an "additional sense code qualifier" with more details. • These details may be provided in an error log by the OS

Error Handling

I/O Protection

• Require all I/O ops to be privileged instructions • This will prevent user processes from disrupting the OS • Protect memory-mapped and I/O memory port locations

from user access, too • Kernel must provide a locking mechanism to allow only

protected access to these features

Kernel Data Structures• Linux makes use of a file descriptor that points to a "per-process

open-file table" This is contained within user-process memory • Within this table there are pointers to file-system records within

the kernel memory • Kernel memory contains: • System-wide open-file table • File-system records • iNode pointer • pointers to r/w functions, select, ioctl, and close

• Network/socket records • Pointer to network information • Pointer to r/w functions • Pointers to select, ioctl, and close

• iNodes are file control blocks in linux - these contain ownership, permissions, and location data for files

Performance• I/O and Network traffic can cause high context switching

rates • Consider keyboard input provided over network. • May wish to use "front end processors" for keyboard I/O and

"I/O channel" cpus on servers to deal with processing of this input

Performance (Contd..)

Offload this work from the main CPU and we do the following: • -Reduce # of context switches • -Reduce memory copying between device and application • -Reduce interrupt frequency • -Increase concurrency • -Use hw commands for I/O processing • -Have better balance of overall device performance,

because more devices may become idle when others become loaded

Next Class:

• Protection - internal OS problem • Mechanisms/Policies • Principles - principle of least privilege • Domains - hw objects and sw objects • Access Matrix • Global table • Access Lists • Capability Lists

• Access control • Language Based Protection

• Security