office hrs: TR 1-2pm, or by appointment (LWSN 1211)
firstname.lastname@example.org, office hrs: TR 9:20-10:20am, HAAS 264
email@example.com, office hrs: M 9-11am, LWSN B132 (6-9444)
PSOs (HAAS 257):
W 9:30-11:20am (Bo)
W 1:30-3:20pm (Xin)
F 11:30-1:20pm (Bo)
F 1:30-3:20pm (Xin)
Operating System Design – The Xinu Approach, Douglas Comer, latest edition
- Additional office hours 5/4/2016, 2:30-4pm, for last minute questions.
- Final exam and QCE: 05/05/2016 (Thu.), 10:30-12:30pm, ME 1061; closed note/book; scope is comprehensive.
- lab4 has been graded. Please follow the same protocol as before (lab4.rpt).
- lab3 has been graded. Please follow the same protocol as before (lab3.rpt).
- The midterm has been graded. Please use the same method as lab scores to access mid.rpt. Copies of: midterm | solution. The solutions are expanded for clarity. Your answers can be more compact while receiving full credit. Send email to both TAs if you have scoring questions.
- lab2/hw2 has been graded. Please follow the same protocol as before (lab2.rpt).
Midterm: 03/10/2016 (Thu.), in-class, closed note/book.
Sample exams: spring 15 | fall 13 | fall 12
- lab1 has been graded. Please follow the same protocol as before (lab1.rpt).
- lab0 has been graded. Your scores are available in grades/<uname>/lab0.rpt in the course directory. <uname> is your user name (i.e., login ID). If you have any questions, please send an email to both TAs.
- Midterm: 03/10/2016 (Thu.), in-class, closed note/book. Further details will follow.
- Note: the class room has moved to ME 2061.
- No PSOs in the first week of class. Although not required, it is strongly recommended that students attend the PSOs where lab assignments are discussed and further TA assistance is provided.
Please follow instructions given in class for accessing lecture slides (pdf).The topics listed below include material not covered in the pdf lecture slides. They should be referenced from class notes and additional pdf slides.
- Review of C function call support: x86 hardware features, gcc and CDECL caller/callee convention.
- Computing systems and OS support evolution: real-world constraints.
- Hardware and software support for isolation/protection.
- x86-specific support: segmentation hardware.
- Linear/flat addressing by neutralizing base/limit bound checking.
- Role of CPL, DPL, IOPL; using int/sysenter to trap in system call, iret/sysexit to return from system call.
- Virtualization: switching between guest kernels and abstraction of shared resources/hardware.
- Full virtualization: design, role of hypervisor, and emulation overhead.
- G. Popek and R. Goldberg. Formal requirements for virtualizable third generation architectures, Communications of the ACM, 17(7):412-421, 1974.
- Process model and multithreading: user space, kernel, and hardware support; their trade-offs.
- Time-share (TS) process scheduling: fairness, CPU- versus I/O-intensive process classification.
- Fair scheduling, implementation issues, and logarithmic scheduling overhead.
- Multi-level feedback queue and constant scheduling overhead.
- Solaris UNIX Dispatch Table Example: TS [dispadmin -c TS -g].
- Real-time scheduling: motivation -- multimedia streaming, periodic tasks with hard deadlines.
- RMS and EDF: admission control, scheduling algorithm, optimality, and performance trade-off.
- Implementation issues: estimating time-varying computation requirements, system overhead, and kernel design
- Compressed video trace of Terminator movie (pdf): variable CPU requirements dependent on compressed frame size.
- C. Liu and J. Layland. Scheduling algorithms for multiprogramming in a hard-real-time environment, Journal of the ACM, 20(1):46-61, 1973.
- Overhead of deadlock detection and kernel approaches to deal with deadlocks.
- IPC: blocking/non-blocking, synchronous/asynchronous primitives.
- Asynchronous IPC with callback function: implementation issues to preserve isolation/protection.
- Why asynchronous device I/O and IPC with callback function are similar.
- Zero-copy I/O: reduction of copy and system call overhead.
- Heavy-tailed lifetime of real-world processes and its impact on multi-processor dynamic load balancing.
- W. Leland and T. Ott. Load-balancing heuristics and process behavior, in Proc. ACM SIGMETRICS, 1986.
- M. Harchol-Balter and A. Downey. Exploiting process lifetime distributions for dynamic load balancing, in Proc. ACM SIGMETRICS, 1996.
- Basic memory management: kernel implementation and user space libraries (e.g., malloc).
- External memory fragmentation: issues and solutions.
- Rationale for hardware supported virtual memory.
- Design of modern memory management support: CPU (including multicores), L1 cache, translation lookaside buffer (TLB), L2 cache, RAM, disk and flash RAM (solid state drives).
- Locality of reference, caching, address translation, average- v. worst-case performance.
- Boundary of responsibility of kernel v. hardware.
- Motivation for multi-level page tables and memory savings (few elephants | many mice), 2-level page table in x86 kernels.
- Relationship between optimal, LRU, and global clock page replacement.
- Thrashing: cause, performance impact, and control mechanisms.
- Linux VM performance (pdf).
- Kernel architecture: upper half and lower half, shared kernel buffer and input/output synchronization.
- Lower half architecture: top half and bottom half division, motivation and their roles.
- Bottom half implementation: passive (context borrowing) vs. active (kernel thread) implementation, trade-offs.
- Implementation in Linux, Solaris, and Windows.
- Kernel, interrupt and DMA controller coordination.
- Video streaming over USB 2.0, FireWire 400 (IEEE 1394a) isochronous mode with DMA hardware support.
- Webcam video streaming example: Linux | Windows I | Windows II
- Types of clocks (system timer, time-of-day clock, high-resolution counter) and their function, x86 specific hardware clocks.
- Tickful kernels: trade-off of small/large tick values.
- Pros/cons of tickful vs. tickless kernel design.
- Real-world file size distribution, "90/10 rule" or "mice and elephants", implication on file system design/performance.
- Log-structured file system: motivation, operation, performance benefits and drawbacks.
- M. Rosenblum and J. Ousterhout. The design and implementation of a log-structured file system, in Proc. ACM SOSP '91, 1991.
- M. Jambor, T. Hruby, J. Taus, K. Krchak and V. Holub. Implementation of a Linux log-structured file system with a garbage collector, in Proc. ACM SOSP '07, 2007.
- Flash memory/SSD file systems: hardware features, performance issues, function of flash translation layer, connection to LFS.
Graduate standing in Computer Science, previous operating system class at the undergraduate level (CS 354 or equivalent), ability to read and understand a large non-trivial system written in C, ability to program extensively in C, and command of system development tools.
The grade will be determined by a midterm, final, and lab assignments. Their relative weights are:
For those planning to take the CS503 Qual 1 examination, the format is the regular final exam plus additional questions. Please contact the instructor for further information.
Labs and Policies
We will use the XINU operating system for the lab assignments. The XINU lab is located in the HAAS Building, room 257. The lab is comprised of frontend machines xinu01.cs.purdue.edu, xinu02.cs.purdue.edu, ..., xinu21.cs.purdue.edu which are Linux PCs. You will use the frontend machines for operating system code development (coding and compiling/linking) and to access one of the backend machines galileo101.cs.purdue.edu, galileo102.cs.purdue.edu, ..., galileo196.cs.purdue.edu. The fronend machines can be remotely accessed via secure shell. They can be used by multiple users concurrently to develop and test code. The backend machines are x86-compatible Intel Galileo boards equipped with Quark X1000 processors that are dedicated to running your implementation of XINU. Thus you are loading/running your own OS binary developed on the frontends on dedicated backend hardware. The specifics of developing and testing code in the XINU Lab will be covered in lab1.
Getting your CS account
Students registered in the course should have an account automatically set up. Please check by going to HAAS 257 and logging in to one of the frontend machines (Linux PCs). If you have registered but don't have an account, please contact firstname.lastname@example.org.
To help manage unexpected scheduling demands, you are given a budget of 3 late days in total that may be used for late submissions of lab assignments. For example, you may submit 1 day late on three lab assignments, or 3 days late on one lab assignment. Any combination is valid as long as the total days delayed does not exceed 3. There will be a total of 5-6 lab assignments. Late days not utilized at the end of the semester will be converted to 25 bonus point each (maximum of 75).Due to the low-level systems nature of the lab assignments, coding and evaluating parts of an operating system running on hardware is time intensive. To encourage proactive handling of assignments, all submissions turned in 2 days prior to its deadline will be given a 8% bonus credit (as a fraction of the points received).
We wish to foster an open and collegial class environment. At the same time, we are vigorously opposed to academic dishonesty because it seriously detracts from the education of honest students. Because of this, we have the following standard policy on academic honesty, consistent with Purdue University's official policy.
It is permissible to discuss a general method of solution with other students, or to make use of reference materials in the library or online. If you do this, you will be expected to clearly disclose with whom you discussed the method of solution, or to cite the references used. Failure to do so will be considered cheating or plagiarism. The use of "method of solution" means a general discussion of technique or algorithm, such as one would reasonably expect to occur standing in front of a whiteboard, and precludes the detailed discussion of code. Specifically, looking at another student's code on his/her computer monitor is NOT allowed.
Unless otherwise explicitly specified, all code that is submitted is to be entirely each student’s own work. Using any code or copying any assignment from others is strictly prohibited without advance prior permission from the instructor. This includes the use of code others have submitted in the past.
All students work is their own. Students who do share their work with others are as responsible for academic dishonesty as the student receiving the material. Students are not to show work to other students, in the class or not. Students are responsible for the security of their work and should ensure that printed copies are not left in accessible places, and that file/directory permissions are set to be unreadable to others (e.g. use "chmod -R 700 *" from your home directory). If you need assistance protecting your work, please contact the TA or the instructor.
Students who encourage others to cheat or plagiarize, or students who are aware of plagiarism or cheating and do not report it are also participating in academically dishonest behavior.
Be aware that we will use a software tool called MOSS to check for copying among submitted assignments. Additionally, the instructor and TA will be inspecting all submitted material to ensure honesty.
Any case of academic dishonesty will be dealt with by a severe grade penalty in the overall class grade and referral to the office of the Dean of Students.
In the event of a major campus emergency, course requirements, deadlines, and grading percentages are subject to changes that may be necessitated by a revised semester calendar. If such unusual circumstances arise, students may determine any such changes by contacting their instructors via email or phone, and checking the course web page for updates.
Emergencies and campus closings will be announced on local media and on the main Purdue University WWW site http://www.purdue.edu. Individuals may subscribe to an SMS text announcement service. Other details are on the Purdue emergency preparedness site.
Emergency preparedness procedures: pdf
This is a graduate introductory course in operating systems that examines how modern operating systems are architected and implemented. Extensive implementation experience is gained by coding, testing, and benchmarking key components of the Xinu operating system on dedicated x86-compatible hardware. A by-product of programming hardware-dependent kernel features in assembly is achieving significant familiarity with x86 hardware, a popular platform of commodity computing systems.
The topics covered in the course include: evolution of operating systems and computer architectures, process management, memory manangement, virtual memory, file systems, I/O subsystems and device management, virtualization and security. In addition to implementing key kernel features in Xinu, we will examine case studies in Linux, UNIX (Solaris and BSD), and Windows that differ from Xinu and each other in significant ways. One important example is how I/O subsystems are architected to handle a range of heterogenous devices and their interrupts, including high-speed USB and wired/wireless network interfaces, that characterize many of today's computing systems. Kernel dependence on changing hardware features and support is an important theme throughout the course that will help familiarize with recent developments such as non-traditional file systems for flash RAM secondary memory prevalent in mobile systems.