E81 CSE 522S: Advanced Operating Systems

Fall 2016

Acknowledgement: this course and web site are adapted (with permission) directly from the original materials
that were developed and taught at Washington University by David Ferry in the spring semester of 2016.

Instructor Chris Gill (office hours by appointment)
Teaching Assistant James Orr (office hours by appointment)
Course Web Site
Backup Web Site
Course Meetings Tuesdays and Thursdays 2:30 PM - 4:00 PM.
Most days will start with lectures and discussions in Cupples II L009,
followed by assisted group work on studios and labs in Lopata Hall 401.
Exams will be held in Cupples II L009 and will occupy the entire meeting time on their designated dates.
Midterm Exam
2:30pm on Thu, Oct 20th, in Cupples II L009
Semester Exam
2:30pm on Thu Dec 1st, in Cupples II L009
Prerequisites CSE 422S (Operating Systems) and C/C++ programming experience

  1. Course Description
  2. Prerequisites
  3. Discussions/Studios
  4. Labs
  5. Course Project
  6. Class FAQ
  7. Textbooks and Other Resources
  8. Grading
  9. Accessibility
  10. Academic Integrity

Course Description

This course intends to give hands-on experience working with the Linux operating system kernel, to address issues well beyond the scope of a basic operating systems course. Profiling, quantifying, modifying, and optimizing operating system behaviors are key themes of this course, as is understanding the policies and mechanisms that govern those behaviors.

The objectives of this course are for each student to:

This is a hands-on graduate-level course dealing with complex systems software, which is currently being taught for the second time this semester. Hiccups are to be expected and finding new and exciting ways to break course exercises is encouraged, as the instructor and teaching assistant seek to fine-tune the content and scope of each class meeting.


Discussions and Studios

This course is conducted in a studio format, both to emphasize the practical and hands-on nature of "kernel hacking" and to engage students in applied active learning exercises. The focus of lecture components is to facilitate in-class discussion of kernel design and features, while the focus of studio exercises is (1) to offer direct experience working within the kernel and (2) to familiarize students with key tools and techniques for kernel development, profiling, analysis, and optimization. Both the studios and the labs will be completed as small group exercises, and are submitted for credit. All studios assigned before the midterm are due the Friday prior to the midterm, and all studios assigned after the midterm are due on the last day of Engineering School classes.

Most class periods are accompanied by suggested readings. The Linux kernel is a particularly compelling subject of study, in that many of the discussions (and disagreements) among the original developers have been saved verbatim in repositories such as the the Linux Kernel Mailing List (LKML) or documented by firsthand witnesses at sites such as The course textbook can be used as a technical reference for kernel mechanisms, and that supplemental readings can be used to understand the particular design choices made in the course of kernel development.

The course schedule is as follows. Note that this schedule may change over the course of the semester. If changes occur, students will be notified in class and given enough advance notice so that readings and other preparation may be accommodated.

# Date Topic Readings Studio/Lab
1 Tue, Aug 30th Course Introduction LKD chapters 1 & 2
Code Pointers
Setting up the Raspberry Pi 3 and building the Linux kernel
2 Thu, Sep 1st How and when does the kernel run? LKD chapter 5
Userspace / Kernelspace API Split
Code Pointers
Creating a syscall
3 Tue, Sep 6th Time sources and timing LKD chapter 11
High Resolution Timers Subsystem
Description of the Timer Wheel System
Introduction of hrtimer Patch (Formerly ktimers)
Code Pointers
Userspace benchmarking
4 Thu, Sep 8th Kernel tracing Ftrace design document
Code Pointers
Tracing with ftrace and Kernelshark
5 Tue, Sep 13th Structure and infrastructure of the Linux kernel LKD pp.85-96
LKD Ch. 6 (as reference material)
LKD pp.338-348
Writing a kernel module
6 Thu, Sep 15th Interrupts and interrupt handlers LKD Ch. 7
LKD Ch. 8
Lab 1 Assigned (due Fri, Sep 30th at 11:59PM)
7 Tue, Sep 20th Processes LKD Ch. 3
LKD Ch. 15
Code Pointers
Process Family Tree
8 Thu, Sep 22nd Traditional process scheduling LKD Ch. 4 Completely Fair Scheduling
9 Tue, Sep 27th Real-time process scheduling Deadline Scheduling vs POSIX Real-time Scheduling
Software Interrupts and Real-time
Real-time Scheduling
10 Thu, Sep 29th Kernel synchronization LKD Ch. 9
LKD Ch. 10
What is RCU, fundamentally?
Kernel Reference on RCU
Synchronizing Threads in the Kernel
Lab 1 due Fri, Sep 30th at 11:59PM
11 Tue, Oct 4th Read-copy-update (RCU) synchronization Read these man pages (run these commands) on a Linux machine:
man 7 futex
man 2 futex
Build Your Own Locks
12 Thu, Oct 6th Overview of the lab 2 assignment   In-class lab (or studio catch-up) time
Lab 2 Assigned (due Fri, Oct 21st at 11:59PM)
13 Tue, Oct 11th Linux details: Program execution and the dynamic linker   In-class lab (or studio catch-up) time
14 Thu, Oct 13th No lecture:
meet James Orr in Lopata 401 at 2:30pm
  In-class lab (or studio catch-up) time
Tue, Oct 18th: Fall Break - no classes

All studios assigned so far are due Wed, Oct 19th at 11:59pm

15 Thu, Oct 20th Midterm review in Cupples II L009   In-class lab time
Lab 2 due Fri, Oct 21st at 11:59PM
16 Tue, Oct 25th Midterm Exam 2:30-4pm in Cupples II L009    
17 Thu, Oct 27th Course projects Course project requirements In-class project plan development time
18 Tue, Nov 1st Inter-process communication: signals
Guest Lecturer: James Orr
  Linux Signals
19 Thu, Nov 3rd Inter-process communication: pipes   Linux Pipes and FIFOs
Project plans due Fri, Nov 4th at 11:59PM
20 Tue, Nov 8th Inter-process communication: sockets   Linux Sockets
21 Tue, Nov 10th Inter-process communication: shared memory   Linux Shared Memory
22 Thu, Nov 15th Linux details: Hardware device drivers   In-class project (or studio catch-up) time
23 Thu, Nov 17th No lecture:
meet James Orr
in Lopata 401 at 2:30pm
  In-class project (or studio catch-up) time
24 Tue, Nov 22nd No lecture:
meet James Orr
in Lopata 401 at 2:30pm
  In-class project (or studio catch-up) time
Thu, Nov 24th: Thanksgiving Break - no classes
25 Tue, Nov 29th Semester Review in Cupples II L009  

All assigned studios are due Wed, Nov 30th at 11:59pm

26 Thu, Dec 1st Semester Exam 2:30-4pm in Cupples II L009    
27 Tue, Dec 6th Project Presentation 1
Project Presentation 2
(meet in Cupples II L009)
28 Thu, Dec 8th Project Presentation 3
Project Presentation 4
(meet in Cupples II L009)

Project code and documents due Fri, Dec 9th at 11:59pm


There will be two lab assignments for this course. The purpose of these labs is to apply course concepts and to evaluate competing design alternatives for kernel mechanisms. As such, each lab will require a written report detailing your findings in addition to a code submission.

Each lab will be completed in a team of two or three students, and teams may be different for each lab. Students from different teams may discuss the lab assignments only during course meeting times. Students on the same team are of course encouraged to discuss and work on lab assignments at any time.

Labs submitted on time (as determined by our email server's receipt time stamp) will be given full credit. Labs submitted up to 24 hours late will be given a ten percent penalty. Labs submitted between 24 and 48 hours late will be given a twenty percent penalty. Labs submitted after 48 hours late will not be given credit, except in the case of extenuating circumstances approved by the instructor.

The following labs have been assigned so far:

Course Project

The course project gives a team of two or three students an opportunity to propose and complete their own significant modification to the Linux kernel. This might be an entirely new capability or it might be an alteration to some existing functionality. The students will evaluate the effectiveness of their modification by developing their own user program test cases that can successfully demonstrate the new behavior. Students are encouraged to look to their own interests and/or research projects for inspiration, and we will also suggest some possible options.

In either case, students will justify their proposal in a written document, in order to ensure that the scope of the project is achieveable. The proposal document will:

  1. Propose a modification
  2. Clearly explain the purpose of the modification
  3. Identify kernel files that will require modification
  4. Identify kernel data structures that will require modification
  5. Identify kernel concepts and control paths that will require modification
  6. Propose a set of user program test cases that demonstrate the modification
  7. Include a five-week planned schedule for the project

The project will be evaluated in part based on a 15-20 minute presentation at the end of the semester, as well as based on submitted code and documentation. This presentation should explain the modification to the class; describe the final alterations to kernel files, data structures, concepts that the students enacted; present timing graphs or other data to verify the behavior of the modified system; and may include a short demo (if possible within the allotted time).

Class FAQ

Current and past instructors, TAs, and students of this course have contributed various tips, tricks, and solutions to problems that they have encountered. Please let your instructor know if you have something you'd like to add here!

Class FAQ

   What if your Pi is freezing up?

   Leaving your Pi at home

Textbook and Class Resources

Students should consider the in-class studios and assigned readings to be a guided tour of the Linux kernel. Like any good tour group, we want to see the sights and learn some neat highlights about who built it and what they were trying to accomplish. But, the studios and assigned readings will not make you an expert on the Linux kernel. When it comes to learning the details of a code base as deep and complex as this, there is no substitute for reading source code. Lectures and studios will come with pointers to relevant source code files, and it is expected that students will spend time absorbing the content there as well. Therefore, assigned readings are kept moderately short with the expectation that you will spend some independent time in the source code.

To be clear, you are not expected to understand or memorize every line of the Linux source. Exams will not have questions derived from the Linux source (though basic kernel concepts and pseudo-code are fair game). However, the kernel is a huge set of deeply interdependent source code files. The only way you will ever understand it is by looking through it many times.

There is one required course textbook: Linux Kernel Development by Robert Love, 2010 (noted as LKD in the assigned readings). This is an excellent, compact, and inexpensive text that gives the reader a basic understanding of kernel design, written with the depth of a kernel veteran.

There are a variety of decent references. None of these will give you the level of competency that comes from looking at code itself, but they are very useful for starting points and clarifying problems. However, the Linux kernel is rapidly updated, so while the general information in these books is correct, details such as source code, names of files, and where files exist is likely to can and does change.

Students will require a Raspberry Pi 3 in order to complete daily studios and lab assignments. The course has been designed with the intention that students bring these devices to class, plug them in, and do some hacking there. Monitors, keyboards, and mice will all be provided for this purpose- you will need to provide the Raspberry Pi 3, a power cord, and an HDMI cable.

If you so desire, you may set up your Raspberry Pi 3 in your home or office and configure it for remote access. However, the instructor cannot support you in this, and we are modifying the kernel so you may be rather lost if you reboot and can't ssh back into your machine. Also, be forewarned that some exercises will require an X11 window, so simple ssh access will not be enough to do everything remotely.


There are four activities for which you will receive credit in this course: studios, labs, exams, and the course project. Studios are daily guided assignments primarily designed to familiarize students with course concepts, development tools, and the kernel source code (i.e. knowledge and comprehension tasks). Two lab assignments will ask students to apply general course concepts and analyze kernel design alternatives. The course project requires that students propose and complete a novel kernel modification. A midterm and semester exam will evaluate your technical understanding of course concepts.

Your grade will be determined as follows:

Activity Grade Percentage
Midterm Exam 10%
Semester Exam 15%
Studios 25%
Lab 1 10%
Lab 2 15%
Course Project 25%


Students with disabilities or suspected disabilities are strongly encouraged both to bring any additional considerations to the attention of the instructor and to make full use of the University's Disability Resource Center (, potentially including accommodations for exam conditions or durations.

Academic Integrity

Each studio, lab, and project assigned in this course is expected to be completed collaboratively by two or three people (and not more or less than that). Student teams may change from assignment to assignment, but the sharing of code between teams is strictly prohibited and you must acknowledge and document in detail all contributions that anyone has made to the work.

Exams must be completed individually without assistance from any other person and without reference to materials or devices, except as specifically allowed by the instructor (documentation of what is allowed will be described in class, provided in the corresponding review slides, and written on the font page of the exam).

Cheating costs everyone something. Someone who cheats misses out on the intended opportunity to improve through the assigned work, and like anyone helping them cheat is at risk of diminshed reputation as well as specific sanctions (see below). Cheating also degrades the value of the degree earned by those who complete their work with integrity.

We take academic integrity very seriously in this course, and anyone found to be cheating or helping someone else cheat will receive a negative score equal in magnitude to the value of the assignment in question (e.g., cheating on an assignment worth 10% of the course grade would result in -10% being assigned for a total loss of 20% from the course grade, which is twice as large a loss as simply not turning in the assignment). Extreme cases also may be referred to disciplinary processes managed by the university. The instructor will make final determinations on what constitutes cheating in this course. If in any doubt, please ask first.

Acadmic integrity is itself worth studying and thinking about as a key component of your education. Please read, familiarize yourself with, and reflect on the Engineering School's and Washington University's undergraduate and graduate policies on academic integrity.