cpuset(1)cpuset(1)NAME
cpuset, miser_cpuset - define and manage a set of CPUs
SYNOPSIScpuset [-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
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 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:
Page 1
cpuset(1)cpuset(1)
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:
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 -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
Page 2
cpuset(1)cpuset(1)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.
Page 3
cpuset(1)cpuset(1)-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:
o 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.
Page 4
cpuset(1)cpuset(1)
o When using the -M or the -T options, JID is not available unless the
feature stream is being used and joblimits is installed.
o 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 ALSOmpadmin(1), runon(1), systune(1M), sysmp(2), boot_cpuset(4), cpuset(4),
cpuset(5), capabilities(4).
IRIX Admin: Resource Administration
Page 5
