CS 736 - Spring 2007 - Paper Discussion

Summary
This paper presents the reader with the concept of resource containers. Resource containers are an effort to create a better abstraction of a "resource principal." Rather than have a process be the consumer of a resource, it would be more intelligent to have an activity be the consumer.

Problem
The problem behind having a process acting as a resource principal seems pretty simple; the process isn't "charged" for any time/resources the kernel spends processing things for the given process. This also introduces subtle problems in accomplishing finely-grained QoS for different processes/users. Resource containers attempt to make everything consumed by a process be capable of being charged to that process, including CPU time and kernel objects.

Contributions
Dispelling the notion that processes should serve as both resource principals and protection domains is only suitable to the most simplistic of applications. Say you have a process that has the kernel processing frequently, such as a network-intensive application (the example provided in the paper). If we are in an environment where processes are the resource principals, then the work done by the kernel will not be "charged" to the process.

The authors discuss a stop-gap solution they have called Lazy Receiver Processing. I call it stop-gap because while processes are correctly charged for networked processing, processes are still used as the resource principal.

The main contribution is of course the eponymous resource container. The essential concept is that scheduling should be associated with an activity, not with a thread or process. In a networked application example, the activity could include CPU time used in the connection along with the required sockets, network buffers, and other kernel objects. Threads from different processes may also be included in the same resource container. By scheduling around activities, it becomes much easier to manage complex resource management issues.

Flaws
The authors mention that in the current model, processes/threads serve as both resource principals and protection domains. In the paper, resource containers are now the resource principals, but there doesn't seem to be any mention of what happens to protection domains. Do they remain associated with processes/threads?

The authors mention that (small, but sometimes pervasive) code changes were needed to make their server applications aware of resource containers. Unless I've misread the performance results, there doesn't seem to be any testing/discussion of what happens when an unmodified application is run with a resource container aware kernel.

There is no satisfying discussion of what would happen if a hostile application attempted to bind its threads to another resource principal.

Performance/Relevance
As the benchmarks indicate, resource containers appear to offer pretty great performance over traditional kernels, especially in a networked application context. It would've been nice to give results for databases or something along those lines.