College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001
CEG 433/633: Operating Systems

Solutions to the 
Final Exam//Summer 2001//75 minutes//100 points

Fine Print:  This was a closed book, closed notes exam.  The following are answers written by a good student,  mildly-edited by your instructor.  He received a near-perfect score in the exam
  1. (6*5 points) The following statements may or may not be (fully or partially) valid.  First, explain the technical terms occurring in the statement.  Then, explain/ discuss/ dispute the statement.  It is possible to write just a few lines, and yet receive full score.
    1. Every Unix program gets argc, argv and envp.
    2. Fragmentation occurs in both file systems and virtual memory.
    3. Program structure has no effect on performance.
    4. Good disk (head) scheduling improves performance
    5. Consider an operating system, such as DOS, that did not provide virtual memory. To such a primitive OS, it is not possible to add-on virtual memory features.
    6. The size of a page must always be a power of 2, where as the size of a segment need not be.

    1a) Argc, argv, and envp are available to all Unix programs. The signature of the main routine controls what is actually accepted. Int main (void) accepts none, where as int main (int argc, char *argv, char ** envp) accepts all 3.

    1b) True. On inode based fs's where disk space is allocated in blocks you get internal fragmentation problems. Similarly, with paging, parts of a page may go unused resulting in internal fragmentation. If a fs uses contiguous allocation, we encounter the problem of external frag. Similarly with a VM system built on straight segmentation, since segments are of multiple sizes, and without compaction, these could be free mem, that is non-contiguous but would be large enough otherwise to satisfy a request. This is also external frag.

    1c) Program structure most certainly has an affect on performance. Consider a 2 x 2 array of 100 columns and 100 rows. If 1 page holds each row and the process is allocated less than 100 pages of mem then

        for (all columns)
            for (all rows)
                array [row] (column) = 0

    could generate up to 100 x 100 pages faults. Simply switching the row and column vars to for (all rows) for (all columns) would only product up to 100 page faults which is a significant savings.

    1d) Good disk head scheduling increases the throughput. Individual process performance may suffer, but system wide, the disk will spend more time actually transferring data than seeking which is what we want. So, overall disk head scheduling may not improve individual process performance, but will increase total system throughput and performance.

    1e) Support for virtual mem (VM) is not just up to the OS. The hardware needs to provide some help in the form of PTBR, PTLR registers, and some TLBs for performance. Other hardware help is  needed so implement segmentation on top of paging. DOS was originally written for an early Intel  architecture that didn't have hardware support for VM. I suppose it would be possible now, to change  DOS to take advantage of the currently provided VM support in Intel chips.

    1f) I suppose it would be possible to write a system for paging where page sizes orient powers of 2  but it would not be a good idea. Page size must be the same as a frame size and RAM (physical mem)  comes in powers of 2; 2MB, 128MB, 512MB, etc. So, non-power of 2 sizes wouldn't fit evenly into  RAM. Besides, powers of 2 are easier to work with. Segments do not have to be in powers of 2.  They are either fit into RAM wherever there is enough space (holes) or implemented on top of paging.

     

  2. (5*5 points) Consider a virtual memory system.
    1. Describe the hardware support needed  for combined segmentation and paging.
    2. Using four (4) frames, and the page reference string
      2513 1234 7623 2615 1263,
      where each digit is a page number, describe the LRU algorithm.
    3. Using the same data, describe the optimal replacement algorithm.
    4. Why do approximations of LRU exist?
    5. Describe thrashing and working set

    2a) Combined segmentation and paging requires the following. Segment Tables and PageTables. In order to implement these efficiently, the hardware must provide PTBR and STBR registers to point to the tables in mem. Also, PTLR, and STLR registers to hold the size of the tables in mem. And for efficiency, some translation lookaside buffers (TLBs) to cache some of the table entries for performance reasons.

    2b) LRU - when no frame is free, replace the least recently used one Example . . .[figure omitted]

    2c) Optimal replacement provides the best possible algorithm. It is only theoretical and is used to benchmark other algorithms. Always replaced block that won't be used for longest time. [figure omitted]

    2d) Approximations of LRU exist because it would be costly to fully implement LRU.  You could add a time field to every page in the table and TLBs but that requires hardware  or software to update the time for every mem access. This is too costly. Similarly, you  could use a stack to store page requests and always know what the LUR page is, but then  you have to manipulate stack pointers for every access. Its much less costly to approx  LRU by simply adding a reference bit, or some other approximation.

    2e) Thrashing is what happens when the system is spending more time paging than  computing. It happens when a program isn't allocated enough frames. It then requests a  lunch of pages, causing faults and steals frames from other processes. These then begin  to fault stealing frames from elsewhere, etc. CPU utilization dips and the schedules starts  more processes, which adds to the problem. Pretty soon the entire system is bogged  down in paging and no real work is being done. 
    The idea of the working set tries to help fix this by telling you approx how many frames a  process needs. You keep track of the last x page requests for a process. The number of  unique page requests in x is the working set size. This approximates the size of the  locality the process is working in. As the working set gets bigger, allocate more frames  to the process. It if shrinks take some away. It may be necessary to suspend other  programs to give one process more frames if they are all being used.

  3. (3*5+10 points) (a) Describe what a device driver is. (b) Sketch the design of a hard disk driver. (c) Sketch the design of a "screen-output" device. (d) Explain how all the above interact in the command ls -lisa > filenm.lst.

    3a) A device driver is a software layer between the I/O subsystem and the hardware controllers of devices. It presents a common interface that abstracts away the details of dealing with a device controller. For instance, it could provide an abstraction for read, such that the I/O layer simply calls read, letting the driver worry about setting control registers for the hardware controller and examining the status, etc. It basically hides the details of the hardware behind a common interface. 

    3b) Hard disk driver provides the following interface read block, write block to a hard disk.

    Read block (block Num) 
    - Set control register of HD controller to read value
    - Set date register of HD controller to block Num
    - Setup DMA transfer address disk can simply write directly to buffer
    - disk goes off and transfers and sets status bit when done, then issues interrupt
    - Check status bit to verify there were no problems
    - Return status

    Write block (block Num) 
    - Set control register of HD controller to write value
    - Set date register to point to location in mem of the block to be written 
    - setup DMA as above
    - disk writes value
    - Check status bit to verify there were no problems
    - Return status

    3c) Screen output driver provides only the write (int screen x, int screen y, value)  interface.

    Write (screen x, screen y, value) 
    -  Resolve (screen x, screen y) to the appropriate address in the video card's bitmap that represents that point.
    -  Set the date registers of the video card to hold the address to write to the value to be written there.
    - video card will then stare value at the appropriate address in the bitmap, which is used to control the screen.

    3d) For each char typed in ls-lisa, call the screen output driver to write the value to  screen.
    -  OS calls disk driver to read blocks containing the inode of the current directory  and all its data blocks
    -  Ls-lisa info is taken for each entry in the directory from its data blocks
    -  The output from ls-lisa is redirected to filename.lst and doesn't appear on screen.
    -  Disk driver is used to write blocks for filename.lsts inode and data blocks which  contain the ls-lisa info.

    Of course in real life, the data blocks are buffered and would only require actual disk I/O  if they weren't in the buffer.

  4. (4*5 points) Explain, at the level of disk blocks, and i-nodes, and other OS internal data structures, what happens when:
    1. a longjmp is executed
    2. a signal is raised
    3. a directory is moved from one directory to another in its parent
    4. a file volume is mounted

    4a) Reload the state of the process, that existed when the desired set jump was executed.  This state info is maintained by the OS with each process. A long jump effectively  rewinds the program to the point the set jump happened. However, I/O etc. is not  undone, program just starts again from set jump point.

    4b) First store all the state attributes of the currently running process, so it can be  resumed. The OS examines the signal mask for the currently running process. If the  signal is not being ignored, the signal table is examined. This stores pointers to routines  used to handle different signal types. The routine for the raised signal is then executed.  The OS provides a default one. The process is then resumed where it left off.

    4c) The directory entry for the directory being moved (which contains its inode number  and name) is removed from the SCC dir and added to the dest driver. No others work  needs be done. This will of course require accessing the inodes of the src and dest  directories, possibly requiring an allocation and addition of a block to the dest dir to add  the new entry and maybe freeing a block from the src dir if only the dir entry being  removed has in it. The updates to size and block list are stored in the src and dest dir  index.

    4d) 1) read the volume's superblock to get volume specific info like block size, free  inodes/blocks, inode array. Reading the superblock also involves creating the in-mem  structures necessary to hold the information. 2) Create an entry in the mount table indicating on which dir in the fs structure the  volume is being mounted.
  October 10, 2001