codconfig - Configures Compaq Capacity on Demand (CCoD)
with the list of initially used (purchased) CPUs
/usr/sbin/codconfig [[-p cpu_id_list] [-l cpu_id_list]
[-c cpu_id_list] ] [-show | -help]
Purchases the CCoD CPUs specified in cpu_id_list that were
not initially purchased. Loans the CCoD CPUs specified in
cpu_id_list to the system as replacements. Makes the CCoD
CPUs specified in cpu_id_list spare CPUs. Indicates
whether or not CCoD has been configured. Displays the list
of CPUs currently initialized for CCoD if it is configured.
Displays a list of CPUs that must be included in the
/usr/sbin/codconfig cpu_id_list command in addition to the
list of available CPUs if CCoD is not configured. Displays
a usage statement that lists the valid options and
syntax for the /usr/sbin/codconfig command.
Configures CCoD with the list of initially purchased CPUs
specified in cpu_id_list.
You must be root or have the appropriate permissions to
use this application.
The /usr/sbin/codconfig command configures CCoD with
capacity CPUs that are either initially purchased with the
system, purchased at a later time, loaned to the system as
replacements, or designated as spares. After you configure
CCoD, purchased or borrowed CPUs remain in the online
state but additional CPUs reserved for expansion are kept
in the offline state.
The /usr/sbin/codconfig cpu_id_list command is used to
configure CCoD with the CPUs that are purchased initially
with the system.
If a purchased CPU needs to be temporarily replaced, you
can loan other capacity CPUs to the system with the
/usr/sbin/codconfig -l cpu_id_list command.
You can bring the purchased or borrowed CPUs on line immediately
(without having to reboot the system) using the
System Management "Manage CPUs" task: /usr/sbin/sysman
When the borrowed CPUs are no longer needed, you can
return them to the spare state with the /usr/sbin/codconfig
-c cpu_id_list command. CPUs that are in the spare
state cannot be put on line until they are either purchased
or loaned to the system.
The -show option displays the CPUs currently initialized
for CCoD if CCoD is configured. If CCoD is not configured,
the -show option displays the list of CPUs that must
remain on line in addition to the list of available CPUs.
The /usr/sbin/codconfig command, when used without options
or a cpu_id_list, displays the same information as the
-show option. See the previous description of the -show
The -help option is a useful reminder of the valid options
and syntax that can be used with the /usr/sbin/codconfig
Mail notifications are sent to the root account when CCoD
is installed, initialized, activated with an additional
CPU, removed from the system, or when a CPU is returned to
the spare state.
See the CCoD README file (/usr/opt/CODBASE520/README.odb)
for more information on Compaq Capacity on Demand.
The CPUs initialized for CCoD must include the primary
(boot) CPU (except on AlphaServer GS Series systems), the
CPUs responsible for managing hardware interrupts, and the
CPUs bound to applications. This is necessary because
these CPUs are in use by the system and cannot be put off
The following information can be used to determine the
specific use of a CPU.
Primary (Boot) CPU [Toc] [Back]
The primary CPU must be included in the cpu_id_list
because it cannot be put off line. The pset_info(1) command
can be used to determine the boot CPU.
For example: # pset_info number of processor sets on system
pset_id # cpus # pids threads load_av created
0 2 31 87 0.00 4/26/2000
total number of processors on system = 2
cpu # running boot_cpu pset_id assigned_to_pset
1 1 1 0 04/26/2000 08:18:31
2 1 0 0 04/26/2000 08:18:31
In the previous example, the 1 in the boot_cpu column
indicates that CPU 1 is the primary (boot) CPU.
Bound CPUs [Toc] [Back]
A CPU that is being used by one or more applications (that
is, the CPU has threads bound to it) must be included in
the cpu_id_list. To determine if a CPU has applications
bound to it, enter the following command from the command
line: # ps -A -o pid,psr,command
The following example shows output of the previous command:
PID PSR COM 458 0 csh 561 0 smsd 567 1
inetd 568 1 dxterm 569 1 ksh 579 ~1 runon 580 ~1
sh 581 ~1 ls -l
In the previous output, the tilde (~) shows that processes
579, 580, and 581 are running *bound* to CPU 1.
Interrupt CPUs [Toc] [Back]
There is currently no exported method of determining the
This version of CCoD is supported only on Tru64 UNIX Versions
5.1A and 5.1B. CCoD is supported only on GS80,
GS160, GS320, ES80, and GS1280 systems.
CCoD must be installed on all systems that have CCoD CPUs
on their system.
CCoD associated SMP licenses must be installed on all systems
that have CCoD CPUs.
CCoD is available on the AlphaServer systems listed in the
RESTRICTIONS section. Use the /usr/sbin/psrinfo -v command
to determine the processor revision.
GS80, GS160, and GS320 systems
The GS80, GS160, and GS320 systems have a Non-Uniform Memory
Access (NUMA) architecture. This can complicate the
choice of which CPU to put on line as memory access speeds
can vary depending on whether the memory being accessed
resides on the same Quad Building Block (QBB) as the new
CPU. There also must be at least one CPU on line in each
QBB to handle any I/O interrupts associated with peripherals
connected to the QBB's PCI drawers.
The CCoD recommendation for GS80, GS160, and GS320 systems
is to start with at least one online CPU per QBB, and then
add CPUs one by one to evenly distribute them across the
QBBs. The CPU IDs can be used to determine in which QBB of
the partition the CPU resides, with the following algorithm:
QBB_number = INT(cpu_id / 4)
For example, on a 4 QBB system with 7 purchased CPUs, the
following CPUs should be on line: 0, 1, 4, 5, 8, 9, and
ES80 and GS1280 systems [Toc] [Back]
The ES80 and GS1280 systems have a Mesh-based Non-Uniform
Memory Access (NUMA) architecture. A mesh is a grid of
CPUs where the CPU on one side of the grid is connected to
another CPU on the far side of the grid. When a CPU on one
of these platforms needs to access either remote memory or
I/O resources local to a different CPU, the traffic is
routed through the mesh to the other CPU. This complicates
the choice of which CPU to put online because memory
access speeds can vary depending on the number of hops
from one CPU to another. CPUs should be placed online so
that the online CPUs are adjacent to one another in the
mesh, and form as square a region as possible.
The xmesh utility can be used to demonstrate how Tru64
UNIX processor identifiers (processor ids) relate to the
mesh; this utility displays a representation for each CPU
with the processor id in its upper left hand corner. The
xmesh utility can be obtained from the
http://tru64unix.compaq.com/manage/xmesh web site.
In addition, the software currently has the following constraints
on placing CPUs offline; these constraints may be
relaxed in the future: The primary CPU can not be placed
offline. A CPU with attached I/O can be placed offline
only if another CPU is available to handle I/O interrupts.
Each CPU can handle I/O interrupts for its own attached
I/O or for I/O attached to another CPU.
The following example shows how to configure CCoD with a
contiguous list of CPU IDs: # /usr/sbin/codconfig 0 1 2 3
The following example shows how to configure CCoD with a
list of non contiguous CPU IDs: # /usr/sbin/codconfig 0 4
8 12 The following example shows how to configure CCoD
with a range of CPU IDs: # /usr/sbin/codconfig 0-3 The
following example shows the CPUs that currently are initialized
for CCoD: # /usr/sbin/codconfig -show
Compaq Capacity on Demand (CCoD) is currently configured:
1 2 3 4
The following CPUs are CCoD spares and can be purchased
or loaned to the system:
5 6 7 8 The following example shows the CPUs that
must be put on line in order to configure CCoD: #
To initialize CCoD, use the following command:
where the cpu_id_list contains 1 or more of the
CPUs in this list:
1 2 3 4
The CPUs not specified will become CCoD CPUs.
0 or Compaq Capacity on Demand (CCoD) has been successfully
>0 An error occurred.
[ Back ]