HP OpenVMS Systems Documentation
OpenVMS System Manager's Manual
27.12 Disabling DECdtm Services
Disable DECdtm services if you do not use, and do not plan to use, any software that uses DECdtm services. This saves memory and CPU time.
In an OpenVMS Cluster, disable DECdtm services on all the nodes in the cluster.
27.13 Enabling DECdtm Services
Enable DECdtm services only if you have previously disabled them and you now want to run software that uses DECdtm services.
This example shows how to enable DECdtm services in a cluster environment.
Deassign SYS$DECDTM_INHIBIT, then start up the TP_SERVER process.
Edit the SYS$MANAGER:SYLOGICALS.COM command procedure to delete the SYS$DECDTM_INHIBIT definition.
|Creating a multiprocessing environment||Section 28.2.1|
|Monitoring a multiprocessing environment||Section 28.2.2|
|+Loading the vector processing support code||Section 28.4.1|
|+Configuring a vector processing system||Section 28.4.2|
|+Managing vector processes||Section 28.4.3|
|+Restricting access to the vector processor with ACLs||Section 28.4.4|
|+Obtaining information about a vector processing system||Section 28.4.5|
|+Loading the VAX Vector Instruction Emulation facility (VVIEF)||Section 28.4.6|
This chapter explains the following concepts:
|Symmetric multiprocessing||Section 28.1|
|Primary and secondary processors||Section 28.1.1|
|Available and active sets||Section 28.1.2|
|Vector processing||Section 28.3|
|+VAX support for vector processing||Section 28.3.1|
|+The VAX Vector Instruction Emulation facility (VVIEF)||Section 28.3.2|
The OpenVMS operating system supports a tightly coupled, symmetric multiprocessing (SMP) system. In a tightly coupled SMP system, all processors execute a single copy of the operating system and have equal access to all operating system code and system resources. OpenVMS SMP dynamically selects the CPU where a process will run based on process priority.
A multiprocessing system can function as an isolated entity, a node in
a network, or a member of an OpenVMS Cluster environment.
Multiprocessing and uniprocessing systems run the same operating
system, although multiprocessing can be enabled only on selected VAX
and Alpha processors. All processors in a multiprocessing environment
must be at the same hardware and firmware level to guarantee that a
given processor is capable of resuming the execution thread of a
process that had
been executing previously on another processor in the system.
28.1.1 Primary and Secondary Processors
In a multiprocessing system, one processor has the responsibility of
starting other processors in the system. The primary
processor is that processor in the system that is either
logically or physically attached to the console device. As such, it is
the processor that is the target of the console commands that boot the
multiprocessing system. In this role, only the primary processor
performs the initialization activities that define the operating system
environment and prepare memory for the entire system. In addition, the
primary processor serves as the system timekeeper, maintaining the
system time and monitoring the timer queue for the expiration of its
elements. In this sense, all processors in a multiprocessing system
that do not have these responsibilities are known as
28.1.2 Available and Active Sets
An available set is made up of the processors that have passed the system's power-on hardware diagnostics and may or may not be actively involved in the system. Together, the primary and the secondary processors comprise the multiprocessing system's available set.
The active set is the subset of the VAX or Alpha
system's processors that have passed power-on diagnostics and are
actively participating in system operations. The operating system
identifies each processor in these sets by its CPU ID, a
value prevalent in the syntax and displays of certain DCL and utility
28.1.3 Processor Capabilities
The processors in a multiprocessing system offer certain capabilities to the processes executing in the system. The following capabilities are supported:
In addition, mechanisms exist to add and subtract other capabilities.
The Run capability affects CPU starting and stopping operations.
28.2 Managing SMP Environments
Managing symmetric multiprocessing systems (SMP) involves creating and
monitoring a multiprocessing environment.
28.2.1 Creating a Multiprocessing Environment
You can control the membership and character of a multiprocessing system at boot time by setting system parameters designed for these purposes. Among the system parameters that manage a multiprocessing system are the following parameters:
|MULTIPROCESSING||Determines which synchronization image is loaded into the operating system at boot time|
|SMP_CPUS||Determines which processors are brought into the multiprocessing environment from the available set at boot time|
For more information about these and other system parameters, refer to the OpenVMS System Management Utilities Reference Manual.
On Alpha systems, you must register the SMP Extension License if you have an SMP system. This license upgrades the Operating System Base License and all Interactive User licenses to the matching multiprocessing level of your system.
Because the SMP Extension License grants all the rights the existing
Base and User licenses provide at the uniprocessing level, reinstalling
those licenses when you upgrade to a multiprocessing system is
unnecessary. When your system is upgraded to a new multiprocessing
level, add an SMP Extension License to your existing license.
28.2.2 Monitoring a Multiprocessing Environment
|Level||Command Example||Display Contents|
|Summary||SHOW CPU||Indicates which processor is primary, which processors are configured, and which processors are active; displays the minimum revision levels for processors in the system and the setting of the MULTIPROCESSING system parameter; and indicates whether multiprocessing is enabled.|
|Brief||SHOW CPU/BRIEF||Produces information from the summary display; lists the current CPU state and the current process (if any) for each configured processor.|
|Full||SHOW CPU/FULL||Produces information from the summary display and displays additional information; lists the current CPU state, current process (if any), revision levels, and capabilities for each configured processor; indicates which processes can be executed only on certain processors.|
For more information about the DCL commands relating to SMP, refer to
the OpenVMS DCL Dictionary; for information about the Monitor utility, refer to
the MONITOR section in the OpenVMS System Management Utilities Reference Manual.
28.3 Understanding Vector Processing
Traditional (scalar) computers operate only on scalar values, and must process vector elements sequentially. Vector computers, on the other hand, recognize vectors as native data structures and can operate on an entire vector with a single vector instruction. Because this type of processing involves the concurrent execution of multiple arithmetic or logical operations, a vector computer can routinely process a vector four to five times faster than a traditional computer can using only scalar instructions.
Vector processors gain a further speed advantage over scalar processors
by their use of special hardware techniques designed for the fast
processing of streams of data. These techniques include data
pipelining, chaining, and other forms of hardware parallelism in memory
and in arithmetic and logical functional units. Pipelined functional
units allow the vector processor to overlap the execution of successive
computations with previous computations.
28.3.1 VAX Support for Vector Processing (VAX Only)
The VAX vector architecture includes sixteen 64-bit vector registers (V0 through V15), each containing 64 elements; vector control registers, including the vector count register (VCR), vector length register (VLR), and vector mask register (VMR); vector functional units; and a set of vector instructions. VAX vector instructions transfer data between the vector registers and memory, perform integer and floating-point arithmetic, and execute processor control functions. A more detailed description of the VAX vector architecture, vector registers, and vector instructions appears in the VAX MACRO and Instruction Set Reference Manual.
Those VAX systems that comply with the VAX vector architecture are known as vector-capable systems.
A VAX vector processing system configuration includes one or more integrated scalar-vector processor pairs, or vector-present processors. Such a configuration can be symmetric, including a vector coprocessor for each scalar, or asymmetric, incorporating additional scalar-only processors. Depending upon the model of the VAX vector processing system, the scalar and vector CPUs of vector-present processors can be either a single, integral physical module or separate, physically independent modules. In either case the scalar and vector CPUs are logically integrated, sharing the same memory and transferring data over a dedicated, high-speed internal path.
Like VAX scalar processing systems, a VAX vector processing system can
participate as a member of a VAXcluster or a node in a network, or be
run as a standalone system.
28.3.2 VAX Vector Instruction Emulation Facility (VAX Only)
The VAX Vector Instruction Emulation Facility (VVIEF) is a standard feature of the OpenVMS operating system that allows vectorized applications to be written and debugged in a VAX system in which vector processors are not available. VVIEF emulates the VAX vector processing environment, including the nonprivileged VAX vector instructions and the vector system services. Use of VVIEF is restricted to user mode code.
VVIEF is strictly a program development tool, and not a run-time replacement for vector hardware. Vectorizing applications to run under VVIEF offers no performance benefit; vectorized applications running under VVIEF execute more slowly than their scalar counterparts.
The operating system supplies the VVIEF bootstrap code as an executive loadable image. Note that, in the presence of OpenVMS vector support code, VVIEF remains inactive. Although it is possible to prevent the loading of vector support code in a vector-present system (see Section 28.4.1) and activate VVIEF, there are few benefits.
See Section 28.4.6 for additional information about loading and
28.4 Managing the Vector Processing Environment (VAX Only)
The following sections describe tasks for managing a vector processing
28.4.1 Loading the Vector Processing Support Code (VAX Only)
By default, in a VAX vector processing system, the system automatically loads the vector processing support code at boot time. You can override the default behavior by setting the static system parameter VECTOR_PROC as described in Table 28-1.
|0||Do not load the vector processing support code, regardless of the system configuration.|
|1||Load the vector processing support code if at least one vector-present processor exists. This is the default value.|
|2||Load the vector processing support code if the system is vector-capable. This setting is most useful for a system in which processors have separate power supplies. With this setting, you can reconfigure a vector processor into the system without rebooting the operating system.|
You can add a vector-present processor to or remove it from a multiprocessing configuration at boot time by using the system parameter SMP_CPUS, or at run time by using the DCL commands START/CPU and STOP/CPU. Note that the operating system treats the scalar and vector CPU components of a vector-present processor as a single processor, starting them and stopping them together.
At boot time, the setting of the system parameter SMP_CPUS identifies which secondary processors in a multiprocessing system are to be configured, including those processors that are vector present. (The operating system always configures the primary processor.) The default value of --1 boots all available processors, scalar and vector-present alike, into the configuration. (Refer to the OpenVMS System Management Utilities Reference Manual for additional information about this parameter.) Note that, prior to starting a vector-present processor, you should ensure that the vector processing support code (see Section 28.4.1) is loaded at boot time. Otherwise, processes will be able to use only the scalar CPU component of the vector-present processor.
To bring secondary processors into a running multiprocessing system, use the DCL command START/CPU. To remove secondary processors from the system, use the STOP/CPU commands. Again, you must ensure that the vector processing support code has been loaded at boot time for the vector CPU component of vector-present processors started in this way to be used.
Note, however, that a STOP/CPU command fails and generates a message if it would result in the removal of a vector-present processor that is the sole provider of the vector capability for currently active vector consumers. In extreme cases, such as the removal of a processor for repair, you can override this behavior by issuing the command STOP/CPU/OVERRIDE. This command stops the processor, despite stranding processes.
When a STOP/CPU/OVERRIDE command is issued for a vector-present processor, or when a vector-present processor fails, the operating system puts all stranded vector consumers into a CPU-capability-wait (RSN$_CPUCAP) state until a vector-present processor is returned to the configuration. To any other process that subsequently issue a vector instruction (including a marginal vector consumer), the system returns a "requested CPU not active" message (CPUNOTACT).
Refer to the OpenVMS DCL Dictionary for additional information about the
START/CPU and STOP/CPU commands.
28.4.3 Managing Vector Processes (VAX Only)
The operating system scheduling algorithms automatically distribute vector and scalar processing resources among vector consumers, marginal vector consumers, and scalar consumers. However, VAX vector processing configurations vary in two important ways:
In a configuration that has more vector consumers in a system than scalar-vector processor pairs to service them, vector consumers share vector-present processors according to process priority. At a given priority, the system schedules vector consumers on a vector-present processor in a round-robin fashion. Each time the system must schedule a new vector consumer on a vector-present processor, it must save the vector context of the current vector consumer in memory and restore the vector context of the new vector consumer from memory. When such "slow" vector context switches occur too frequently, a significant portion of the processing time is spent on vector context switches relative to actual computation.
Systems that have heavy vector processing needs should be adequately configured to accommodate those needs. However, some mechanisms are available for tuning the performance of an existing configuration.