User manual

Introduction

can and likely will enter into a livelock approximately the same way as in the case of single instance, with

the same consequences.

Do not overcommit your system by configuring more virtual CPUs in all VAX MP concurrently

running instances combined than the number of host logical CPUs available (counting host

hyperthreaded units).

Doing do will cause your host system to lock up and will require hardware reset of the host

machine.

Furthermore, depending on host operating system being used, as a practical matter we recommend to

configure a smaller number of VAX VCPUs than the number of LCPUs available on the host system, and

set a fraction of host computational capacity aside. This reserved capacity can be used both by VAX MP

internal threads other than VCPU threads (such as VAX MP disk, tape and network device IO threads,

virtual clock interrupt thread and console thread), by host operating systems services and other

processes, and by host OS user interface, including window manager and terminal emulator windows. If

VCPU threads had to compete with UI threads, this can cause system response such as terminal output

to feel choppy.

The need to set LCPUs aside depends on the qualities of host OS scheduler. In our experience, Windows

7 and OS X 10.7.4 do not require any LCPUs to be set aside. With Linux 2.6.38 it is advisable to set one

LCPU aside for best interactive responsiveness. With Windows XP, best interactive responsiveness is

reached with two LCPUs set aside.

For example, host machine with Intel i7 quad-core hyperthreaded processor allows to configure an

instance of VAX MP with up to 8 VAX virtual processors. When running Windows 7 or OS X as host

operating system, all 8 can be used. When running Linux on the same host machine, it is better to

configure only 7 VAX processors. If using Windows XP as host OS, it is more pragmatic to limit

configuration to 6 VAX virtual processors, and to set remaining two LCPUs aside as a reserve for guest

OS system functions and for VAX MP auxiliary (non-VCPU) threads. Such configuration would execute

smoother and have better interactive responsiveness.

Similarly, while it is possible to configure two concurrent 4-processor VAX instances to run on the same

i7 quad-core host machine under Linux, it is advisable to limit one of them to 3 VAX processors (thus

totaling 7 VCPUs for two instances) and set the remaining LCPU aside for host functions.

Setting some minimum host capacity reserve aside may have also other potential benefit, especially

when running VAX in production mode. In an unlikely case of OpenVMS deadlock due to some system

failure, all VCPU threads may end up spinning at high host thread priority. If there were no host capacity

set aside, it would be impossible for host system administrator to intervene short of hardware reset on

the host machine.

VAX MP is runnable on cache-coherent SMP systems with no or very low NUMA factors. VAX/VMS and

OpenVMS VAX assume flat uniform symmetric memory access for all the processors and do not