Section 7.1. Projects and Tasks Framework

7.1. Projects and Tasks Framework

In this section, we describe the central administration objects that are used for resource management, observability and accounting in Solaris.

7.1.1. Introduction

The project and task entities are used in Solaris to describe workloads, which consist of a set of related processes. Processes are grouped into tasks, tasks are a member of a project. Projects and tasks are used to control and observe the resources of a workload. Some of the key uses for the Project and Tasks in Solaris are:

• They provide an attachment point in the basic administrative model for controlling resources. Various system facilities including the Solaris resource manager fair share scheduler (See Section 3.7.3.3), the IP Quality of Service (IPQOS) and the Resource Pools infrastucture. This provides a unification of implementation aspects of the various forms resource management within the Solaris operating environment. For example, if want to limit a workload consisting of a group of processes to be entitled to at least 50% of the CPU resources on the system, we would define a project for that workload, and then configure the resource manager allow the specified resource entitlement within that project.

• As an entitity to observe and record the resource consumption of a workload. For example, we wanted to report the total CPU consumption of all of the proceses in a workload, we could use prstat to display resource utilization on a per-project basis, using prstat -J.

• To meter and enforce resource limits across sub-components or all of a workload. For example, if we wanted to limit the maximum amount of shared memory resources that a workload can allocate, then we could set a per-project resource limit on that resource.

Figure 7.1. Projects and Tasks Hierarchy

7.1.2. Projects

The project participates in the administrative model at a level equivalent to a user or group ID. A user who is a member of more than one project can run processes in multiple projects at the same time. All processes that are started by a process inherit the project of the parent process. When you switch to a new project in a startup script, all child processes run in the new project.

An executing user process has an associated user identity (uid), group identity (gid), and project identity (projid). Process attributes and abilities are inherited from the user, group, and project identities to form the execution context for a task.

7.1.3. Tasks

A task is a group of related processes associated with a project. Processes inherit their project and task identifiers across fork(2) and exec(2); a new task is created when a new project identifier is bound to a process. Resource consumption by a task is charged to a project. The resources tracked by the accounting system are configurable systemwide.

The project acts as a source of resources to be made available to that same collection of related work, allowing resource controls and limits to be set for each task. Section 7.5.

Tasks are formally distinct from sessions (see setsid(2)) so as to avoid unnecessarily contaminating the semantics of tasks with the semantics of terminals. A new task is created for each login session when the user's project is bound to the user's login shell. Within a login session, the project ID can be changed with the newtask(1) utility. This command can also be used to run applications against different projects in the same session while preserving full shell task control semantics for the invoking shell.

7.1.4. Why We Added Tasks to Solaris

The basic requirements for tasks stem from the associated accounting capabilities: the actions of a task must be accountable, and the set of actions must be equivalent to the typical actions performed during an interactive login or a queue submission. Furthermore, an interactive user must be able to switch projects during his login session. There were two viable process aggregates in standard UNIX implementations: process groups and sessions:

• Process groups are not a valid solution, since every pipeline forms a new process group. Tasks include pipelines as well as other commands in a given sequence, so process groups aren't semantically large enough to accommodate the definition of a task.

• The POSIX session is large enough to contain the accountability attributes of a task, but its additional property of an associated controlling terminal prevents it from supporting the ability to switch projects (or charge codes) during an interactive login. The following limitations on a session-based approach:

  	Multiple sessions cannot share a terminal without an intermediary.
  	newtask, as an intermediary, would need to pass through all task control signals, including SIGKILL, to its children.
  	newtask cannot protect stdin and stdout from the other competing sessions. More succinctly, a controlling terminal cannot sensibly be shared by two sessions.

  
  

For these reasons, and to avoid any compatibility complications from changes to the POSIX session definition, the task is introduced as an unencumbered entity to represent a distinct family of related processes in Solaris.