From tamda@eecg.utoronto.ca Fri Feb 14 19:14:53 2003 Date: Fri, 14 Feb 2003 19:12:09 -0500 (EST) From: David Kar-Fai Tam To: Angela Demke Brown Cc: Reza Azimi , Adrian Tam Subject: CSC2227 project proposal CSC2227: Advanced Topics in Operating Systems Design Term Project Proposal Implementing Resource Containers in K42 David Tam, Adrian Tam, Reza Azimi Feb. 14, 2003 Introduction ------------ We plan to implement resource containers in the K42 operating system. A resource container is a mechanism to track resource consumption of a particular user while criss-crossing process/domain boundaries. This is a problem in current operating systems since their model of resource accounting does not necessarily reflect the actual usage pattern of a user. Part of the CPU usage charged to a user process may be eaten by preemptive system tasks such as interrupt-handling. Moreover, a single user application may cross several resource domains (processes) which deceives the process-based resource accounting model. To address this problem, there have been efforts [1] to decouple resource accounting from the process model and assign resource usage directly to the users. This scheme makes resource accounting more accurate and, as a result, is more effective in providing quality-of-service and security guarantees (such as preventing DoS attacks). Currently, accounting of resources in such a manner is not available in K42. Without this mechanism, resource account is inaccurate and can lead to undesired behaviour. Requirements ------------ Implementing resource containers in K42 will be an interesting and challenging problem. First, we will be implementing resource containers under a multiprocessor context, whereas the seminal paper [1] was implemented for a uniprocessor. Second, resource containers must not have a detrimental impact on the performance and scalability features of K42. Third, implementing resource containers requires fundamental changes in various sections of the kernel source code. There is no clear, definite modular decomposition to encapsulate the changes required. The changes will be scattered throughout the kernel source code. Modifications ------------- To understand the modifications that are required, we must think of how resource containers operate. The simplest description is that when a process makes a request to another process, the resource container is transferred along with the request. Once the callee process has completed servicing the request, the resource container is transferred back to the caller. In terms of K42, it means that the IPC facility (Protected Procedure Call PPC) must be modified to transfer the resource container. Another required change is to the kernel-level scheduler. It must be modified to account for resource usage statistics in the resource container and make appropriate scheduling decisions. Our goal is to implement resource containers for 3 major resources: 1. CPU usage 2. memory consumption 3. network bandwidth Methodology ----------- The steps that must be taken are the following: 1. Design and implement the basic mechanism (IPC mods, kernel scheduler mods, implementing resource containers as clustered objects [2]). 2. Run benchmarks and ensure the new mechanism does not have negative effects on system performance and scalability. 3. Enable resource accounting in the resource containers. 4. Measure impact on overhead. 5. Make incremental changes so resource containers account for CPU usage. 6. Evaluate system performance in the presence of functional resource containers. 7. Implement and evaluate memory usage accounting in resource containers. 8. Implement and evaluate network bandwidth accounting in resource containers. We feel that the above methodology results in a fairly scalable project. Depending on the nature of the difficulties that we encounter in our (complex) operating system, we can easily scale up or down the project. At the completion of each stage, we will evaluate system functionality & performance. This will give us something to measure along each step of the path and enable us to easily demonstrate progress. Task Division ------------- We can evenly divide the task of implementing the basic mechanism into: 1. Modifications to the PPC facility to transfer resource containers. 2. Implementing resource containers as clustered objects [2] for MP performance and scalability. 3. Modifications to the kernel-level scheduler to handle resource containers. We can also evenly divide the task of making modifications so resource containers account for CPU, memory, and network usage. Miscellanea ----------- For formality, we are supposed to describe how this project relates to the course material, so here goes... This project is about adding a new mechanism to an existing complex system (the K42 operating system). This project will involve topics such as concurrent programming, synchronization and deadlock detection/avoidance, and dealing with large, complex systems. We will design, construct, and evaluate the effectiveness/impact of the resource container mechanism under the context of a multiprocessor operating system designed for scalability. Hopefully, we will encounter many problems related to system size & complexity and be able to overcome them by the end of the project, thus learning many valuable lessons about dealing with complex systems. References ---------- [1] Gaurav Banga and Peter Druschel and Jeffrey C. Mogul, "Resource containers: A new facility for resource management in server systems", OSDI 1999. [2] Jonathan Appavoo, "Clustered Objects: Initial Design, Implementation, and Evaluation", Master's Thesis, University of Toronto, 1998.