cpuset(1)
cpuset, miser_cpuset - define and manage a set of CPUs
As shipped in IRIX 6.5.15. Last changed in IRIX 6.5.15.
NAME cpuset, miser_cpuset - define and manage a set of CPUs SYNOPSIS cpuset [-q cpuset_name [-A command]|[-c -f filename]|[-d]|[-l]|[-m] |[-Q]|[-p]] | -C | -Q | -h DESCRIPTION The cpuset command is used to create and destroy cpusets, to retrieve information about existing cpusets, and to attach a process and all of its children to a cpuset. A cpuset is a named set of CPUs, which may be defined to be restricted or open. A restricted cpuset only allows processes that are members of the cpuset to run on the set of CPUs. An open cpuset allows any process to run on its cpus, but a process that is a member of the cpuset can only run on the CPUs belonging to the cpuset. A cpuset is defined by a cpuset configuration file and a name. See cpuset(4) for a definition of the file format. The cpuset configuration file is used to list the CPUs that are members of the cpuset. It also contains any additional parameters required to define the cpuset. A cpuset name is between three and eight characters long; names of two or less characters are reserved. The file permissions of the configuration file define access to the cpuset. When permissions need to be checked, the current permissions of the file are used. It is therefore possible to change access to particular cpuset without having to tear it down and recreate it, simply by changing the access permissions. Read access allows a user to retrieve information about a cpuset while execute permission allows the user to attach a process to the cpuset. Cpusets on IRIX requires two user classes: root and user. The root class creates, destroys, moves a process, and adds a process to the cpuset. The user class is governed by the file permissions of the configuration file for the given cpuset. Given a configuration file with the following characteristics: Permissions Owner Group Size Filename -------------------------------------------------- -rwxr----- root cpuset 512 cpuset.test Group read permission allows a user belonging to the group cpuset to list all cpusets in the cpuset defined by the cpuset.test file and get a listing of all processes in this cpuset. In order for the user to add processes to the cpuset governed by the cpuset.test file, you would need to change the permissions as follows: Permissions Owner Group Size Filename -------------------------------------------------- -rwxr-x--- root cpuset 512 cpuset.test In a Trusted IRIX environment, permissions are governed by the /etc/capability file. See the capability(4) and capabilities(4) man pages for more information on the capability mechanism that provides fine grained control over the privileges of a process. Each user in the capability file has a set of minimum and maximum permissions. Consequently, root does not have any special abilities except to be able to use suattr so that it may assume any capabilities and permissions. Capabilities and permissions are also narrowed by the use of mandatory access control (MAC) labels and access control lists (ACLs). In Trusted IRIX, to allow a user belonging to the group cpuset to list all cpusets in the cpuset defined by the cpuset.test file and get a listing of all processes in this cpuset, you must perform the following: o Assign the user with a MAC label of userlow. o Make the following entry in the /etc/capability file: cpuuser1:all=:all= You can not assign a user all capabilities with effective, inherited, and permissive rights (+eip) added. If you add +eip, the user will gain more privileges than allowed by the Cpuset system. A Trusted IRIX user with a cpuuser1:all=:all= entry in the /etc/capability file, has the same permissions as the user class in IRIX. The root class in Trusted IRIX must have the CAP_SCHED_MGT+eip capability to create and destroy cpusets and to move process out of the cpuset. In Trusted IRIX, you can use ACLs to control group permissions. With ACLs, you can easily select which users in the group can add a process to the cpuset. You can use ACLs to control a user's access to a cpuset without that user belonging to the group owner of the configuration file. OPTIONS -q cpuset_name -A command Runs the command on the cpuset identified by the -q parameter. If the user does not have access permissions or the cpuset does not exist, an error is returned. -q cpuset_name -c -f filename Creates a cpuset with the configuration file specified by the -f parameter and the name specified by the -q parameter. If the cpuset name already exists, a CPU specified in the cpuset configuration file is already a member of a cpuset, or the user does not have the requisite permissions, the operation fails. -q cpuset_name -l Lists all the processes in the cpuset. -q cpuset_name -m Moves all the attached processes out of the cpuset. -q cpuset_name -d Destroys the specified cpuset. A cpuset can only be destroyed if there are no processes currently attached to it. -q cpuset_name -Q Prints a list of the cpus that belong to the cpuset. -q cpuset_name -p Prints out the permissions, ACLs, MAC labels, flags, number of processes and the cpus associated with the specified cpuset. -C Prints the name of the cpuset to which the process is currently attached. -Q Lists the names of all the cpusets currently defined. -h Print the command's usage message. RESTRICTIONS A CPU can belong to at most one cpuset. CPU 0 cannot belong to an EXCLUSIVE cpuset. A CPU cannot be both restricted or isolated (see mpadmin(1) and sysmp(2)) and also be a member of a cpuset. Only the superuser can create or destroy cpusets. Only the superuser can move all processes out of a cpuset (-m option). runon(1) can not run a command on a cpu that is part of a cpuset unless the user has write or group write permission to access the cpuset's configuration file. DETAILS There is a tuneable system parameter, in the static parameter group, miser called cpuset_nobind. By default the boolean parameter is set to '0' or false. When this parameter is set to '1' (true), a further restriction is placed upon processes scheduled by cpuset: If cpuset_nobind == 1, Then no process scheduled by cpuset may bind itself or a child process to any cpu. The request to bind to a cpu will be refused and the error code set to EPERM. In addition a message will be sent to the console and SYSLOG explaining the failure. NOTES In a cluster environment, the cpuset configuration file should reside on the root filesystem. If the cpuset configuration file resides on a filesystem other than the root filesystem and you attempt to unmount the filesystem, the vnode for the cpuset remains active and the unmount (see unmount(1M) command fails. Make sure that your workload manager sets the configuration file to reside on the root filesystem. SEE ALSO mpadmin(1), runon(1), systune(1M), sysmp(2), boot_cpuset(4), cpuset(4), cpuset(5). IRIX Admin: Resource Administration