I/O Systems ◦ Operating Systems ◦ CS550

Note:  Based on Operating Systems Concepts by Silberschatz, Galvin, and Gagne  Strongly recommended to read Sections  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 calls Asynchronous 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 sockets o checks if network I/O is possible by using a wait time of zero as a parameter This is a non-blocking operation o "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 Buffers 1.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 Caching 1.Cache - fast memory to hold copies of data 2.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. 3.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