cpuset(1) cpuset(1) NAME cpuset, miser_cpuset - define and manage a set of CPUs SYNOPSIS cpuset [-q cpuset_name[,cpuset_name_dest] [-A|-V command] |[-c|-L -f filename]|[-d]|[-i]|[-l]|[-m]|[-M]|[-Q]|[-p] |[-T]] | -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 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 memdev 512 cpuset.test Group read permission allows a user belonging to the group memdev to list all processes in the cpuset defined by the cpuset.test file. 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 memdev 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 memdev to list processes in the cpuset defined by the cpuset.test file you must perform the following: + Assign the user with a MAC label of userlow. + 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 -f filename -V command Creates a volatile cpuset identified by the -q parameter and specified by the -f parameter, and then runs the command in the cpuset. This command may be executed by users without the scheduling capability. The cpuset will be destroyed by IRIX as soon as the last thread in the cpuset exits. Resources specified for the cpuset via the configuration file, filename, must be from the set of nodes identified previously via the command cpuset -L. -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, the cpus and the node memory associated with the specified cpuset. -q cpuset_name,cpuset_name_dest -M suboption The -M option moves a process or a group of processes and their associated memory from cpuset_name to cpuset_name_dest. The valid suboptions are PID, ASH, JID, SID, and PGID indicate the id type to be moved. The -M option also requires the -i option. -q cpuset_name,cpuset_name_dest -T suboption The -T option moves a proces or a group of processes but not their memory from cpuset_name to cpuset_name_dest. The valid suboptions PID, ASH, JID, SID, and PGID indicate the id type to be moved. The -T option also requires the -i option. -q cpuset_name,cpuset_name_dest [-M | -T] suboption -i id The -i option tells the command what id needs to be moved. -L This command queries IRIX for the maximum set of resources available for use by volatile cpusets. -L -f filename This command loads into IRIX the configuration specified by the -f parameter. This configuration limits the nodes that volatile cpusets may use. -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 or a user with the CAP_SCHED_MGT capability can create or destroy cpusets. Only the superuser or a user with the CAP_SCHED_MGT capability 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 dynamic 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. An additional tuneable system parameter, in the same group, is cpuset_tobind. By default the boolean parameter is set to '0' or false. When this parameter is set to '1' (true), a restriction is placed upon processes attempting to bind to a CPU via the sysmp(2) MP_MUSTRUN option requiring the target CPU to be restricted or isolated via mpadmin(1) , or part of a cpuset. NOTES When using the -M or the -T options, the follwing items apply: + When moving processes out of a cpuset to the general cpu pool (global_cpuset), use the value of 0 as the dest_cpuset. Likewise, use the value of 0 as the source_cpuset when moving processes from the global_cpuset to a specific cpuset. + When using the -M or the -T options, JID is not available unless the feature stream is being used and joblimits is installed. + IRIX will not allow processes stopped for job control to be migrated. When cpuset moves a stopped process, it sends the process a SIGCONT, moves it, and then stops it again. 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), IRIX Admin: Resource Administration Page 5