Document revision date: 19 July 1999

The OpenVMS operating system supports the following special environments:

• Symmetric multiprocessing
• Vector processing (available only on certain CPU models)

This chapter describes how to set up and manage these special processing environments.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Creating a multiprocessing environment	Section 26.2.1
Monitoring a multiprocessing environment	Section 26.2.2
+Loading the vector processing support code	Section 26.4.1
+Configuring a vector processing system	Section 26.4.2
+Managing vector processes	Section 26.4.3
+Restricting access to the vector processor with ACLs	Section 26.4.4
+Obtaining information about a vector processing system	Section 26.4.5
+Loading the VAX Vector Instruction Emulation facility (VVIEF)	Section 26.4.6

This chapter explains the following concepts:

Concept	Section
Symmetric multiprocessing	Section 26.1
Primary and secondary processors	Section 26.1.1
Available and active sets	Section 26.1.2
Vector processing	Section 26.3
+VAX support for vector processing	Section 26.3.1
+The VAX Vector Instruction Emulation facility (VVIEF)	Section 26.3.2

A multiprocessing system consists of two or more CPUs that address a common pool of memory and that are capable of executing instructions simultaneously.

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.

26.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 secondary processors.

26.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 commands.

26.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:

• Primary
• Quorum
• Run
• Vector (VAX Only)

In addition, mechanisms exist to add and subtract other capabilities.

The Run capability affects CPU starting and stopping operations.

26.2 Managing SMP Environments

Managing symmetric multiprocessing systems (SMP) involves creating and monitoring a multiprocessing environment.

26.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:

Parameter	Function
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.

You can add an available processor to the active set at boot time, or you can add it later using the DCL command START/CPU. The DCL command STOP/CPU removes a processor from the active set.

SMP Extension License

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.

26.2.2 Monitoring a Multiprocessing Environment

Several operating system features provide special information about the character, capabilities, and status of a multiprocessor system. They include the DCL command SHOW CPU and the Monitor utility.

Obtaining Information About a Multiprocessor Configuration

The SHOW CPU command displays three levels of information describing the configuration and status of a multiprocessing system:

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.

26.3 Understanding Vector Processing

A single data item, having one value, is known as a scalar. A group of related scalar values, or elements, all of the same data type, is known as a vector.

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.

26.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.

26.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 26.4.1) and activate VVIEF, there are few benefits.

See Section 26.4.6 for additional information about loading and unloading VVIEF.

26.4 Managing the Vector Processing Environment (VAX Only)

The following sections describe tasks for managing a vector processing system.

26.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 26-1.

Table 26-1 Settings of VECTOR_PROC System Parameter (VAX Only)

Value	Result
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.

26.4.2 Configuring a Vector Processing System (VAX Only)

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 26.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.

26.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:

• The amount of vector processing activity the configuration must accommodate
• The number of vector-present processors that are available in the configuration to service vector processing needs

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.

26.4.3.1 Adjusting System Resources and Process Quotas (VAX Only)

Systems in which several vector consumers are active simultaneously may experience increased paging activity as processes share the available memory. To reduce process paging, you may need to use the Authorize utility (AUTHORIZE) to adjust the working set limits and quotas of the processes running vectorized applications. (Refer to the AUTHORIZE section of the OpenVMS System Management Utilities Reference Manual for additional information.) An increase of the process maximum working set size (system parameter WSMAX) may also be necessary. Additionally, a vectorized application may use the Lock Pages in Working Set system service ($LKWSET) to enhance its own performance.

The system allots to each vector consumer 8KB of system nonpaged dynamic memory in which the operating system stores vector context information. Depending upon how many vector consumers may be active in the system simultaneously, you may need to adjust the system parameter NPAGEDYN. The DCL command SHOW MEMORY/POOL/FULL displays the current size of nonpaged pool in bytes.

To obtain optimal performance of a VAX vector processing system, you should take some care in setting up generic batch queues that avoid saturating the system's vector resources. If a queue contains more active vectorized batch jobs than vector-present processors in the system, a significant portion of the processing time will be spent on vector context switches.

The recommended means for dispatching vectorized batch jobs to a VAX vector processing system is to set up a separate queue (for instance, VECTOR_BATCH) with a job limit equal to the number of vector-present processors in the system. When submitting vectorized batch jobs, users should be encouraged to submit them to this generic vector-processing batch queue.

26.4.3.2 Distributing Scalar and Vector Resources Among Processes (VAX Only)

As a vector consumer, a process must be scheduled only on a vector-present processor. If the image the process is executing issues only scalar instructions for a period of time, and it must share the scalar-vector processor pair with other vector consumers, its inability to run on an available scalar processor could hamper its performance and the overall performance of the system.

By default, the operating system assumes that if a vector consumer has not issued a vector instruction for a certain period of time, it is unlikely that it will issue a vector instruction in the near future. The system relinquishes this process's need for the vector capability, classifying it as a marginal vector consumer.

In an asymmetric vector-processing configuration, detection of marginal vector consumers achieves the following desirable effects:

• Because a marginal vector consumer is eligible to run on a larger set of processors, its response time will improve.
• The scheduling of marginal vector consumers on scalar processors reduces the contention for vector-present processors.
• Because vector consumers issuing vector instructions are more likely to be scheduled on vector-present processors, the vector CPU is more efficiently used.

Use the VECTOR_MARGIN system parameter to establish the interval of time at which the system checks the status of all vector consumers. The VECTOR_MARGIN parameter accepts an integer value between 1 and FFFFFFFF₁₆. This value represents a number of consecutive process quanta (as determined by the system parameter QUANTUM). If the process has not issued any vector instructions in the specified number of quanta, the system declares it a marginal vector consumer.

The default value of the VECTOR_MARGIN parameter is 200₁₀.

	privacy and legal statement
6017PRO_102.HTML