Section 7.4. Kernel Infrastructure for Projects and Tasks

7.4. Kernel Infrastructure for Projects and Tasks

Several new data types and system calls were added for projects and tasks.

7.4.0.1. Project and Task System Calls

New id_t equivalent types distinguish task and project associations within the kernel as well as interfaces that can determine these attributes for a process.

typedef id_t    taskid_t; typedef id_t    projid_t; /*  *      The following defines the values for an identifier type.  It  *      specifies the interpretation of an id value.  An idtype and  *      id together define a simple set of processes.  */ typedef enum {         P_PID,          /* A process identifier.                */         P_PPID,         /* A parent process identifier.         */         P_PGID,         /* A process group (job control group)  */ ...         P_TASKID,       /* A task identifier.                   */         P_PROJID,       /* A project identifier.                */ ... } idtype_t;                                                                       See sys/procset.h 

The settaskid(2) system call causes the calling process to be associated with the project identifier projid. The new task identifier that results from a successful change of project is returned to the caller. The task identifier returned is allocated from an ID space independently of the space used for process identifiers. You can issue settaskid() with the TASK_FINAL.

The getprojid(2) system call returns the project ID associated with the current process. The gettaskid(2) system call returns the task ID associated with the current process.

7.4.1. System Call Interaction with Projects

Certain system calls have additional code that implement the new administrative model. The fork(2) and exec(2) family of routines ensure that the task_id and project_id are inherited across these operations. The exit(2) system call writes extended process accounting records, as well as to update the task accounting information on process termination. Extensions to the implementation of sigsend(2) and sigsendset(2) allow signals to be sent to tasks; no additional privilege is granted over that available for existing processes to execute kill(2) on one another.

Extensions to the implementation of priocntl(2), pset_bind(2), and processor_bind(2) allow the idtype argument to be set to P_TASKID so that the function applies to all lightweight processes (LWPs) currently associated with processes in the specified task.

7.4.2. proc(4)

The task_id and project memberships are visible through the proc(4) file system, via the the psinfo file. It can be read without any special permission, as with the other identifiers for the process: the parent process ID, the process group leader, the session ID, etc. This allows allow ps(1) to report a process's task membership while remaining an unprivileged executable.

7.4.3. In-Kernel Project Data Structures

A dictionary of all active projects is maintained by the kernel so that we may track project usage and limits. (By an active project, we mean a project associated with one or more tasks, and therefore with one or more processes.) The dictionary is built on top of the mod_hash facility, based on the assumption that project additions and deletions are relatively rare events. An integer-to-pointer mapping is maintained within the hash, representing the map from project id to project structure. All projects, including the primordial "project 0", are allocated via the project_hold_by_id() interface.

typedef struct kproject_data {          /* Datum protected by: */         rctl_qty_t      kpd_shmmax;     /* shm's ipcs_lock */         rctl_qty_t      kpd_shmmni;     /* shm's ipcs_lock */         rctl_qty_t      kpd_semmni;     /* sem's ipcs_lock */         rctl_qty_t      kpd_msgmni;     /* msg's ipcs_lock */         rctl_qty_t      kpd_devlockmem; /* umem_devlockmem_rctl_lock */         rctl_qty_t      kpd_contract;   /* contract_lock */         rctl_qty_t      kpd_crypto_mem; /* crypto_rctl_lock */ } kproject_data_t; /*  * The first two fields of this structure must not be reordered.  */ typedef struct kproject {         projid_t        kpj_id;         /* project ID           */         zoneid_t        kpj_zoneid;     /* zone ID              */         uint_t          kpj_count;      /* reference counter    */         uint32_t        kpj_shares;     /* number of shares     */         rctl_set_t      *kpj_rctls;     /* resource control set */         struct kproject *kpj_prev;      /* previous project     */         struct kproject *kpj_next;      /* next project         */         kproject_data_t kpj_data;       /* subsystem-specfic data */         kmutex_t        kpj_poolbind;   /* synch. with pools    */         rctl_qty_t      kpj_nlwps;      /* protected by project's zone's */                                         /* zone_nlwps_lock */         rctl_qty_t      kpj_nlwps_ctl;  /* protected by kpj_rctls->rcs_lock */         rctl_qty_t      kpj_ntasks;     /* protected by project's zone's */                                         /* zone_nlwps_lock */         rctl_qty_t      kpj_ntasks_ctl; /* protected by kpj_rctls->rcs_lock */ } kproject_t;                                                                       See sys/project.h 

Currently, the project contains a reference count; the project ID, which is examined by the extended accounting subsystem as well as /proc; a resource control set, which contains the allowable values (and actions on exceeding those values) for controlled project-level resources on the system; and a number of CPU shares, which is used by the fair share scheduling class (FSS) to support its proportion-based scheduling algorithm.

There is a mdb(1) dcmd and walker for projects:

> ::project     ADDR PROJID ZONEID REFCNT d9ada680      0      0    455 d5b2fa00      0      1    167 d5b2f380      0      2    150 d692fec0      0      3    163 d692fe40      0      4    175 d5b2f680      0      5    175 d5b2f600      0      6    176 d5b2f580      0      7    183 d5b2f500      0      8    197 d87a3840     10      7      4 d8bc17c0      1      1      5 dc6a4bc0     10      3      5 db34c040      3      0      5 > ::walk projects d9ada680 d5b2fa00 d5b2f380 d692fec0 d692fe40 d5b2f680 d5b2f600 d5b2f580 d5b2f500 d87a3840 d8bc17c0 dc6a4bc0 db34c040 

7.4.3.1. Reference Counting Convention

The dictionary entry does not itself count as a reference--only references outside of the subsystem are tallied. At the drop of the final external reference, the project entry is removed. The reference counter keeps track of the number of threads *and* tasks within a project.

7.4.3.2. Locking

Walking the doubly-linked project list must be done while holding projects_list_lock. Thus, any dereference of kpj_next or kpj_prev must be under projects_list_lock.

If both the hash lock, project_hash_lock, and the list lock are to be acquired, the hash lock is to be acquired first.