HP OpenVMS System Manager's Manual, Volume 2:...

Managing Special Processing Environments

Understanding Vector Processing

Managing DECdtm Services

Managing the Vector Processing Environment (VAX Only)   

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 Settings of VECTOR_PROC System Parameter (VAX Only).

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

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 HP 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 Loading the Vector Processing Support Code (VAX Only)) 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 HP OpenVMS DCL Dictionary for additional information about the START/CPU and STOP/CPU commands.

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.

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

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₁₀.

Restricting Access to the Vector Processor by Using ACLs (VAX Only)  

A vector capability is a software abstract by which the operating system makes the services of the vector processor available to users. You can restrict the use of the vector processor to users holding a particular identifier by associating an access control list (ACL) with the vector capability object.

For example, a university might limit use of the vector processor to faculty and students in an image processing course, or a service bureau might charge users for access to the vector capability, time spent on the vector processor, or both.

Use the DCL command SET SECURITY/ACL in the following format to establish access control entries (ACEs) on a vector capability:SET SECURITY /CLASS=CAPABILITY /ACL=(ace[,...]) VECTOR

The following DCL command displays the ACL on the vector capability:

$ SHOW SECURITY /CLASS=CAPABILITY VECTOR

For additional information about the SET SECURITY and SHOW SECURITY commands, refer to the HP OpenVMS DCL Dictionary.

Obtaining Information About a Vector Processing System (VAX Only)  

You can obtain information about the status of the vector processing system and the use of the system by individual processes through various means, including:

• The DCL lexical functions F$GETJPI and F$GETSYI



• The DCL command SHOW CPU



• The DCL commands SHOW PROCESS and LOGOUT/FULL



• The Accounting utility



• The Monitor utility

DCL Lexical Functions F$GETJPI and F$GETSYI (VAX Only)  

The DCL lexical function F$GETJPI accepts the following items and returns the corresponding information regarding the vector status of a specified process:

Item	Return Type	Information Returned
FAST_VP_SWITCH	Integer	Number of times this process has issued a vector instruction that resulted in an inactive vector processor being enabled without the expense of a vector context switch
SLOW_VP_SWITCH	Integer	Number of times this process has issued a vector instruction that resulted in an inactive vector processor being enabled with a full vector context switch
VP_CONSUMER	Boolean	Flag indicating whether the process is a vector consumer
VP_CPUTIM	Integer	Total amount of time the process has accumulated as a vector consumer

The DCL lexical function F$GETSYI accepts the following items and returns the corresponding information regarding the status of the vector processing system:

Item	Return Type	Information Returned
VECTOR_EMULATOR	Integer	Flag indicating the presence of the VAX Vector Instruction Emulation facility (VVIEF) in the system
VP_MASK	Integer	Mask indicating which processors in the system have vector coprocessor
VP_NUMBER	Integer	Number of vector processors in the system

Refer to the HP OpenVMS DCL Dictionary for additional information about the DCL lexicals F$GETJPI and F$GETSYI.

SHOW CPU/FULL Command (VAX Only)  

The SHOW CPU/FULL command lists the capabilities of the specified CPU. Issue this command to determine the presence of the vector capability in the system prior to executing a STOP/CPU command.

Refer to the HP OpenVMS DCL Dictionary for additional information about the SHOW CPU command.

SHOW PROCESS and LOGOUT/FULL Commands (VAX Only)  

If the target process has accrued any time as a vector consumer scheduled on a vector-present processor, the DCL commands SHOW PROCESS and LOGOUT/FULL display the elapsed vector CPU time and the charged vector CPU time, respectively.

To accumulate vector CPU time, a process must be a vector consumer (that is, require the system vector capability) and be scheduled on a vector-present processor. The operating system still charges the vector consumer vector CPU time, even if, when scheduled on the vector-present processor, it does not actually use the vector CPU. Note that, because scalar consumers and marginal vector consumers do not use the vector CPU, they do not accrue vector CPU time, even when scheduled on a vector-present processor.

Refer to the HP OpenVMS DCL Dictionary for additional information about the SHOW PROCESS and LOGOUT commands.

Loading the VAX Vector Instruction Emulation Facility (VVIEF) (VAX Only)  

The VAX Vector Instruction Emulation Facility (VVIEF) is a standard operating system feature that allows vectorized applications to be written and debugged in a VAX system in which vector processors are not available. VVIEF is intended strictly as a program development tool, and not as a run-time replacement for vector hardware. Vectorizing applications to run under VVIEF offers no performance benefit; vectorized applications running under VVIEF will execute more slowly than their scalar counterparts.

To cause the system to load VVIEF at the next system boot and at each subsequent system boot, invoke the command procedure SYS$UPDATE:VVIEF$INSTAL.COM. To unload VVIEF, invoke the command procedure SYS$UPDATE:VVIEF$DEINSTAL.COM and reboot the system.

You can determine the presence or absence of VVIEF in a system by issuing the following DCL commands:

$ X = F$GETSYI("VECTOR_EMULATOR") 
$ SHOW SYMBOL X
X = 1   Hex = 00000001  Octal = 0000000001

Note that, although VVIEF may be loaded into the system, in the presence of vector support code, it remains inactive. Although it is possible to prevent the loading of vector processing support code in a vector-present system (see Loading the Vector Processing Support Code (VAX Only)) and activate VVIEF, there are few benefits. Should the only vector-present processor in the system fail, the execution of preempted vectorized applications will not resume under VVIEF.

Understanding Vector Processing

Managing DECdtm Services