Objectives - In completing this class, students will...

• understand key concepts involving system resource management, organization, and abstraction
• understand how an OS manages and interfaces with hardware
• understand fundamental trade-offs integral to system design
• experience both development and experimentation in a real OS
• understand how to read a research paper
• understand how to write a review for a research paper
• understand how to give a research presentation, and to discuss the presentation of research

Prerequisites:

• Computer Architecture or Operating Systems
• Assignments for this class will be done in C, and will require kernel-level programming. Though we do not assume that you have kernel experience, if you aren't somewhat comfortable with C, you will have a very difficult time. Thus, a familiarity with C or a willingness to quickly learn and practice it is required.

  If you are not comfortable with C, at least go through Essential C and the exercises in the Course Material Section.

Responsibilities - Students must

1. Attend all classes unless you are sick or there is an emergency, in which case you must email the Professor.
2. Interact, ask questions, and generally participate in class discussions.
3. Complete programming problems assigned.
4. Devote significant amounts of time to a large implementation project on low-level systems that will require a significant amount of debugging. You cannot procrastinate on this.
5. Give presentations throughout the class on research papers. You must prepare thoroughly for this. See the item below on how to present research.
6. Be proactive in learning on your own. You will encounter many ideas you are unaccustomed to, or unaware of. You must do your own research online to understand the concepts well enough to explain and discuss the research papers.
7. Students must write quality code. You must read Composite Style Guide to understand one perspective on this.

The work for this course includes:

• An initial programming assignment to give you a taste of what's required for the semester project.
• Weekly, you will either 1) present research papers, or 2) read two of the research papers being presented on that day. For the former, it is your responsibility to email me a draft version of your presentation 72 hours previous to your presentation (Friday at 6pm), and be available to correct any mistakes and integrate my feedback. Send your email with the subject CSCI6907:Presentation Draft. If you do not send this 72 hours early, or don't name the email correctly (I use email filters to view these emails), your grade for the presentation will have 20% removed from it. Your job is to best present the main topics of your chosen paper(s). See the tips below for how to present research papers. For the latter (reading papers), it is your responsibility to send me an email by 5pm before the class with your paper summaries. They must be included in the body of the email and cannot appear as attachments. You must name your email CSCI6907:Paper Review. Again, your grade will suffer if these guidelines are not followed.
• You will work in a group with a maximum size of 2 members on a semester-long project. I will circulate a list of project ideas soon. You are free to choose one of them, or create your own, pending my approval. If you create you're own, you must discuss the idea with me via email by 1/24/14. The project will include an interim presentation and report half way through the semester in which your group presents their progress, a final presentation and report at the end of the semester that presents the final state of your project. You will, lastly, hand in your code with documentation and a README file describing how to build and test the code. This project will be the largest component of your grade.

Reading Research Papers

Reading and understanding research papers is a skill that you will develop throughout the course. The most important concept to understand when you're done reading a paper is "what was the purpose of the research"? In answering this, you will define the contributions of the paper. You should have a general idea of what the contributions are after reading the abstract and introduction, but keep them in mind throughout the entire paper, as they provide motivation for how the system is implemented, and how it is evaluated (which tests are done). Often you will change your understanding of the contributions as you learn more about the techniques used, and the previous related work. An analysis of the paper is an important aspect of understanding a piece of research. It forces you to critically think about the research. When analyzing a paper, you want to answer what you liked about the research and the techniques, and what are its limitations? These limitations often revolve around assumptions the approach makes, the generality (or lack there-of) of the approach, etc... Each piece of research has a limited applicability, has limitations to its technical approaches, and has limits to its motivation. An important piece of paper analysis is to identify these as they define possible future research. As you read through a paper, I highly recommend that you take notes (I often write in the side-bars of the paper). Lastly, you should note any questions that you have about the paper. These can be about topics ranging all the way from technical aspects of the paper, all the way up to high-level questions about the motivation of the paper. Anything you don't understand, should go into this section.

The summary must include three short sections (title them in your email with the corresponding titles below):

1. Contributions. A 1 to 3 sentence summary of the purpose of the paper (i.e. what is its contribution?).
2. Analysis. A paragraph or two including an analysis of the paper.
3. Questions. A list of questions you have about the paper that is unlimited in length. You are not expected to understand 100% of each paper, and the questions you may have can be part of the class discussion.

These summaries should not be long, so please try and be concise. In fact, the more concise they are, the better. The contents of the analysis and questions should often follow directly from notes you made while reading the paper. You should bring a copy of each paper to class.

Presenting Research Papers

Making presentations for research papers can be difficult, but if you keep a few things in mind it should organize your approach. First, you should aim for a presentation that is about 30 minutes without interruption. You must practice your presentation and time it. Second, it is important to convey in your presentation the motivation for the approach taken in the paper. Next, you will answer the question, "what is the problem being addressed by the paper?" This might include how other systems have insufficiently approached the same problem, how some specific application scenarios necessitate the research, etc... After the motivation, the implementation details should be presented. You should not include all details here. Instead, you should focus on the most important details essential for understanding the empirical evaluation. If minute details are important, we can look at the paper directly. Last, you want to discuss how the authors justify their system through empirical evaluation. What tests do they do, why, and what are the results. You will not have enough time to go through all of the results so choose representative results that reinforce the main contributions of the paper.

Often presentations already exist online for some papers (especially the more recent ones). You can feel free to use content from these presentations (I encourage it) but you must include attributions and credits appropriately. If you do not do this, you are plagiarizing (see Academic Honesty below).

General advice on giving good presentations and writing good papers can be found here.

If you're behind and having trouble with C, here is a list of references. You must go through these on your own, and very early in the semester.

• a good short refresher/introduction is Nick Parlante's Essential C, memory and pointers, linked lists, and linked list problems. These are reproduced from here. The Linked List problem sets are especially useful.
• A few resources from our Software Engineering course (i.e. csci2113).
• If you're having trouble understanding what a specific declaration is in C, use the cdecl command, or, if it isn't installed, you can use the cdecl webpage.
• For those of you who know C, but want to learn how to write better C, one source is the Composite Style Guide.

It is your responsibility to get up to speed in C, so please use these resources.

Once you are more advanced in C, it will be useful to read the style guide for Composite, our research OS here at GWU.

The course is structured around three segments, each with a different theme. These are parallelism and scalability, reliability and fault tolerance, and security. An elaboration on each:

• Parallelism and scalability. With the broad adoption of multi-core systems, and the increasing number of cores on these systems, it is essential to understand how to design systems to take advantage of the increased computation. This segment will investigate research platforms that make novel contributions into how systems are designed for parallelism.
• Reliability and Fault Tolerance. It is difficult to write code. It is even more difficult to write systems code. It is truly amazing that any system of sufficient complexity (e.g. Linux, Windows, Browsers) works at all. The cracks in this software frequently show when they become faulty. This could be as bad as systems crashing, or locking up, or as annoying as the application simply not following specification. In this segment, we will discuss how people design systems to provide fault-tolerant execution environments to increase the reliability of the system.
• Security. The need for security needs no explanation. What is less clear, is what Operating Systems can do to become more secure that goes beyond simply "trying not to write exploitable code". This segment will discuss the many ways in which systems can themselves increase the level of security of the entire system.

All topics will focus on the operating systems executing on a single computer. A future class (taught by Prof. Wood) will focus on distributed systems issues.

Homework 1 due 1/31/14: For this homework, you will implement a slab allocator. Find the original paper here. This paper is not very clear, and you will want to seek out other resources to learn more about slab allocators. However, you must still implement the API and general design introduced in this paper. Through this homework, you will learn:

• The importance of slowly writing and thinking about code.
• The utility of assertion statements.
• The importance of paying attention to performance in code design.
• How to write systems code in C, if you didn't already have experience with it.

Please see the academic honest section below. You are not allowed to copy other's code either from classmates or from the Internet. All of the code must be your own. For this assignment, you are not allowed to work in groups. You must implement this in C, and provide your own thorough test cases. You must use proper structuring of your project into *.c and *.h files. The quality of your code matters. Please focus on simplicity, and if a section of your code is becoming complex, do back up and simplify. That said, the fundamental operations of allocation and deallocation should not take more than around 100 cycles, so performance matters too.

Details:

• Implement the API from Section 2.3 with the following exception: You don't need to implement constructors and destructors, so they don't need to appear in you cache allocation function.
• kmem_cache_grow can simply use malloc, and kmem_cache_reap can use free (described in 3.1).
• You are free to ignore what the paper calls "memory pressure" which is essentially the system asking for memory back. Instead, and unlike what section 3.4 suggests, you can free a slab immediately when no objects in it are allocated.
• It is essential to understand what a freelist is, and how it is used in the slab allocator. For example, you should understand that in the common case where there are cached objects available, allocation and free should be O(1) operations.
• You should only use malloc and free when allocating new slab, and not when you allocate or free a new object. To do this, you must understand that the freelists can be held within object memory itself, as, by definition, that object memory is unused if it is on a freelist.
• You can ignore section 4.
• It will help to read about malloc implementations, and understand how memory allocators are implemented in general. One reasonable implementation is dlmalloc, that is quite googleable.
• A concise, fully functional implementation is possible in around 200 lines of code. If you are going much beyond that, then ask if you are making it more difficult than it needs to be.

Project and Group Selection -- Deadline Feb 15th, midnight: Please send me one email per group that includes 1) a list of group members (either one or two members permitted per team), and 2) a prioritized list of projects you're interested in. Your list must include all projects, properly prioritized. The subject line of the email should be CSCI6907: Project Selection.

Project suggestions include:

• Microkernel system evaluation. This project will focus on the area of systems research of system evaluation. You will figure out how to install and use three different microkernels: L4 Fiasco, L4 Pistachio, and seL4/OKL4. Installing each of these will be challenging, and you'll want to first explore and debug the process in QEMU, or in a virtual machine. Then you will want to evaluate each on a multi-core system (preferably with at least 4 cores).

  The evaluation will include writing small programs (or, more likely, using existing programs and perhaps slightly modifying them) to test important system functionalities such as IPC latency (known as "ping-pong") between threads on the same core, and across cores, the cost of asynchronous IPC between threads, and the cost of mapping and unmapping memory under different conditions. The goal of this evaluation will be to determine what the average and worst-case costs of each operation are the impact of interference (from shared memory coherency traffic) from other cores. This project will include reading the code of some of these systems to determine what the interesting cases to evaluate are.

  This project, completed thoroughly and with care, could provide a comparison case that is needed in a future publication.

• High throughput, controlled latency client processing system. We have done some initial work on defining a system that runs on multi-core systems, and handles client requests, each of which must gain access to a number of shared data-structures. The synchronization mechanisms must not only be fast, but also latency-aware. That is, the system must have a high throughput, but must also not let any client fall too far behind in the amount of time it takes to process. Many systems that power google adwords client auctions have exactly these constraints. We have worked with a company that motivated this problem.

  This project will develop a suite of software to handle client requests, and synchronize between their access to shared data. First, we need the arrival time of each client request, so that we can synchronize based on its deadline. This part of the project will modify libevent to immediately read client requests, tag them with the arrival time, and send them via wait-free ring buffers to each of the other cores. Next, you will continue work already done in defining a deadline-aware spin-lock. Last, you will compare this implementation versus a few other spin-lock implementations.

  This project, implemented well and completely has a possibility of publication. Doing so will require quite a bit more work.

• SQLite in a component-based embedded operating system. Composite is the component-based operating system we are developing at GWU. One of the features it is sorely lacking is a sufficient data-base. This project will port the SQLite data-base to Composite. This project will 1) compile and work with SQLite, 2) work with Composite and learn aspects of it such as the torrent interface, 3) port SQLite to this environment, and 4) write test scripts to demonstrate the use of SQLite, and perhaps provide access through the webserver.

  Successful and careful implementation of this project will result in your code being added to Composite, and your name added to the list of contributors!

Please ask questions about each of these on Piazza. You want to assess which are the most interesting to you, so ask questions to help with that.

Paper schedule:

Please sign up for presentations using the link published on Piazza.

• Introduction to the class

Grades will be assigned using the following breakdown:

• 15%: Project - interim report and presentation
• 20%: Project - final report and presentation
• 20%: Project - code quality and functionality
• 15%: Presentations - research paper presentation
• 15%: Paper summaries - Sufficient, yet concise summary of research papers throughout the class
• 15%: Participation - You must participate in class. You will get these points mainly for that participation, but also for participating on Piazza.

You cannot get credit for any component of the class if you hand it in late.

Just as you can do a google search for code online, it is trivial for us to do the same. We have caught numerous people cheating in the past in this way. If you feel pressured about an assignment, please come see me instead of cheating.

You are not allowed to collaborate on the homeworks and the lab assignments. The group projects require collaboration amidst each group, but no collaboration between teams is permitted. Please refer to the academic integrity policy linked from the course web page. This policy will be strictly enforced. If you're having significant trouble with an assignment, please contact me.
Academic Integrity Policy
Credit: I'd like to thank Prof. Narahari for the first versions of this academic honesty policy.

If you're interested in Composite, the OS we are developing here at GW, don't hesitate to contact me.

In addition to the contents of the class, what follows is a list of resources that will allow you to go beyond what you've learned. This material is not mandatory for the class and is meant to give you a springboard if you wish to pursue the ideas further. Many of these are blog posts or articles for easy reading. However, because of the informal format, please take the contents with a grain of salt. I can point you to more thorough content if you want it. If you find an website/article/tool that you think is worthy of being in this list, let me know.

Websites geared toward systems topics (or that have subsections on systems):

• Linux Weekly News: Free content is that which is at least a week old (see the Archives).
• Two brilliant classes on microkernel construction.
• Arstechnica: geek news, often with a high-level overview of systems/architectural topics.
• OKLabs videos. A microkernel company. Specifically, see the series titled, "Advanced OS with Gernot Heiser".
• OSDev Wiki: the resource on practical OS construction and hardware manipulation.
• Agner's blog: What's happening in those processors of ours? See more architecture discussions at real world tech.
• From low-level embedded system hacking, to robotics, to hacking! Hackaday!

Blogs and articles (remember that these are not authoritative sources!):

• On binaries and understanding process layout: A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux, and playing with binary construction.
• On memory management: A look at how malloc works on the Mac, and memory allocation -- magic no more!
• On transactional memory (a synchronization mechanism):A (brief) retrospective on transactional memory
• Concurrency via events or threads? Why not both! And how do you provide an interface to it?
• A great email thread about efficient IPC implementation.
• What every programmer should know about memory. Seriously. He's not kidding. Read this. And look at the motivational graphs.
• Like file systems? Get some history.
• Higher-level description of a modern filesystem, ZFS
• On the hardware manipulations necessary to boot an OS: Roll your own toy UNIX-clone OS.
• A simple UNIX clone: xv6.
• Correct use of virtual memory: You're Doing It Wrong.
• Intricacies of C,v1, v2, v3, and v4 ...and you thought C was simple.
• How do they build the large-scale distributed systems at Google? Here's a hint!
• A history of networking physical level with ethernet, and a great history of UNIX
• Interface design is difficult. Where did UNIX get it wrong? Must read for anyone thinking about designing an interface.
• On the Brokenness of File Locking, or "why interface design matters".
• A great resource on parallel programming.
• Browsers don't do magic either! They are just very, very, very complex beasts.
• Why low-level programming matters even if you don't plan on doing it in the future.
• Premature optimization may be the root of all evil. But sometimes understanding how to do it is essential.
• Coding style matters. Read how others have decided on a style: Linux and Composite
• Reasonable lists of historical publications that have defined computing as we know it.

Really. cool. tools:

• DynamoRIO: Because it rocks to modify a program as it's executing.
• SQLite: a small, well written, data-base. Use it, read it, and be merry.
• Lua: a tiny language with a runtime of about 10K LOC. If you want to know what a language does under the wraps, here's a good place to find out (just ignore some of the syntax oddities).
• Valgrind: Ever wonder what your program's been doing in its spare time? This will tell you. Required for debugging large C/C++ programs.
• LLVM: A beautiful compiler backend. If you want to write a language, this will make your life so much easier.
• FUSE: Want to write a file-system, but aren't sure about all of that kernel programming? And what if you need to use high-level libraries? No problem; do it is user-space!
• Daikon: Because who doesn't want to use machine learning to infer their own program's behavior?
• More powerful link-time optimization!
• A great C library for simple machine learning operations such as classification.