Citation:
Banga, G., Druschel, P., and Mogul, J., "Resource Containers: A New Facility
for Resource Management in Server Systems", Proceedings of the Third Symposium
on Operating Systems Design and Implementation, New Orleans LA, February 1999,
pp. 45-58.

* Summary

Current operating systems combine the notions of protection domain and resource
principal in the process abstraction. However, this severely limits the 
control and scheduling of machine resources by applications, preventing them 
from providing robust quality of service. This is especially prominent for
network servers that handle large numbers of network connections. The authors
introduce resource containers as a new operating system abstraction that 
separates the notion of a protection domain from that of a resource principal,
and show how they enable fine-grained resource management and control.

* Why We Need Resource Containers

Existing operating system APIs do not allow for fine-grained resource 
management and control by applications. Instead, the kernel controls all
consumption of resources needed by the application. Even when explicit
resource management mechanisms do exist, they are tied to the assumption
that a process is what constitutes an independent activity. However, modern
high-performance servers (e.g., Web servers) use a single process to perform
many independent activities. With the kernel controlling consumption of
resources, it is impossible for the server application to provide priority 
service among its clients.

* Resource Containers

A resource container encompasses all system resources that the server uses to 
perform an independent activity. All user and kernel processing for an activity
is charged to the appropriate resource container, and scheduled at the priority
of the container.

With resource containers, the binding between a thread and a resource principle
is dynamic, and under the explicit control of the application. This binding is
called the thread's resource binding. The kernel charges resource consumption
to the currently bound container. Applications can change a thread's binding,
which is useful for example when a thread is time-multiplexed among a number of
connections.

By allowing applications to associate scheduling information with an activity,
resources can be provided directly to it. However, when a thread is being
multiplexed among multiple containers, scheduling it according to only the 
currently bound container may misrepresent its recent resource usage. In order
to prevent such a situation, the idea of a scheduler binding is used. A 
scheduler binding is maintained between each thread and the set of containers
over which it is currenly multiplexed. The kernel is responsible for observing
the recent activity of a thread, and maintaining the appropriate scheduler
binding. However, an application is free to explicity reset a thread's 
scheduler binding to only the currently associated container.

Resource containers can be used hierarchically to conrol the resource
consumption of an entire subsystem without constraining how the subsystem
allocates and schedules resources among its various activities. Hierarchical
resource containers are supported by the parent container abstraction, where
applications can explicity set the parent of a given container.