cpuset(1) cpuset(1)
cpuset, miser_cpuset - define and manage a set of CPUs
cpuset [-q cpuset_name [-A command]|[-c -f filename]|[-d]|[-l]|[-m]
|[-Q]|[-p]] | -C | -Q | -h
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:
Page 1
cpuset(1) cpuset(1)
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.
-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.
Page 2
cpuset(1) cpuset(1)
-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.
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.
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.
Page 3
cpuset(1) cpuset(1)
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.
mpadmin(1), runon(1), systune(1M), sysmp(2), boot_cpuset(4), cpuset(4),
cpuset(5).
IRIX Admin: Resource Administration
PPPPaaaaggggeeee 4444 [ Back ]
|
