One-line Summary
A resource container is an operating systems abstraction that separates the notion of a protection domain from a resource principal. It allows for fine-grained resource management.
Paper Structure Outline
Typical models for high-performance servers
Shortcomings of current resource management models
The distinction between scheduling entities and activities
Integrating network processing with resource management
Consequences of misidentified resource principals
A new model for resource management
Containers, processes, and threads
Resource containers and CPU scheduling
The resource container hierarchy
Operations on resource containers
The use of resource containers
Performance
Prioritized handling of clients
Controlling resource usage of CGI processing
Immunity against SYN-flooding
Isolation of virtual servers
Background & Motivation
In resource management, current systems do not separate the notion of "protection domain" (where the accounting of the tasks is done) and "resource principal" (where actual work gets performed). Processes and threads are both resource principals as well as protection domains. Also, an application does not have control over how much resources the kernel consumes on behalf of the application. In this work, the two notions are separated by the new operating systems abstraction, resource containers.
Existing models include (1) process-per connection, (2) single-process event-driven connection, and (3) multi-threaded server.
The authors then presented some analyses in section 3 to analyze the shortcomings of the current models.
Design and Implementation
Instead of binding threads of application space processes, threads bind to different resource containers (RC), a new abstraction that extends into the kernel and thus has knowledge of which os entities are doing work for which application-level clients. Resource containers logically contain all types of resources (CPU time, sockets, control blocks, network buffers) being used by an application. Containers are also attached with attributes to limit resources (CPU availability), provide scheduling priorities, and network QoS values.
To use resource containers with multiple threads:
Threads are assigned to RCs for each new connection as soon as identified from request info
Kernel processing is charged to this container
We can have different RCs for different QoS policies
The OS scheduler appropriately schedules threads by priority/resource usage. If the thread consumes more than its fair share of resources, its scheduling priority decays.
To use resource containers with events:
Threads switch to the desired resource containers as they handle new events
No need for scheduling by OS
The associated container will be charged for the processing the thread performs for them
Resource containers just track accounting
Applications use the information to determine the order to handle events
Resource containers allow explicit and fine-grained control over resource consumption at both user-level and kernel-level. They can provide accurate resource accounting, enabling web servers to provide differentiated QoS.
Restricting resource usage of dynamic requests allows the OS to deliver a certain degree of fairness across containers RCs are effective in the prioritized handling of clients (have better response time) as they prevent work in the kernel Resource utilization can be controlled by isolating static requests being serviced Containers help provide a certain amount of immunity against a DOS attack by SYN flooding. Resource principals: Entities for which separate resource allocation and accounting are done
Protection domain: Entities that need to be isolated from each other
CS 736 course slides on resource containers by Prof. Andrea Arpaci-Dusseau
