Check out the new USENIX Web site. next up previous
Next: Kernel execution model Up: A new model for Previous: The resource container hierarchy

   
Operations on resource containers

The resource container mechanism includes these operations on containers:

Creating a new container:
A process can create a new resource container at any time (and may have multiple containers available for its use). A default resource container is created for a new process as part of a fork(), and the first thread of the new process is bound to this container. Containers are visible to the application as file descriptors (and so are inherited by a new process after a fork()).

Set a container's parent:
A process can change a container's parent container (or set it to ``no parent'').

Container release:
Processes release their references to containers using close(); once there are no such descriptors, and no threads with resource bindings, to the container, it is destroyed. If the parent P of a container C is destroyed, C's parent is set to ``no parent.''

Sharing containers between processes:
Resource containers can be passed between processes, analogous to the transfer of descriptors between UNIX processes (the sending process retains access to the container). When a process receives a reference to a resource container, it can use this container as a resource context for its own threads. This allows an application to move or share a computation between multiple protection domains, regardless of the container inheritance sequence.

Container attributes:
An application can set and read the attributes of a container. Attributes include scheduling parameters, memory allocation limits, and network QoS values.

Container usage information:
An application can obtain the resource usage information charged to a particular container. This allows a thread that serves multiple containers to timeshare its execution between these containers based on its particular scheduling policy.


These operations control the relationship between containers, threads, sockets, and files:

Binding a thread to a container:
A process can set the resource binding of a thread to a container at any time. Subsequent resource usage by the thread is charged to this resource container. A process can also obtain the current resource binding of a thread.

Reset the scheduler binding:
An application can reset a thread's scheduler binding to include only its current resource binding.

Binding a socket or file to a container:
A process can bind the descriptor for a socket or file to a container; subsequent kernel resource consumption on behalf of this descriptor is charged to the container. A descriptor may be bound to at most one container, but many descriptors may be bound to one container. (Our prototype currently supports binding only sockets, not disk files.)


next up previous
Next: Kernel execution model Up: A new model for Previous: The resource container hierarchy
Gaurav Banga
1998-12-17