On /390 servers also make use if possible of the option of dedicated CPUs (see section"VM2000 scheduling (/390 servers)"):
In VM2000 operation without additional CPU pools, all available real CPUs are used for scheduling the (virtual) CPUs of all guest systems. For systems for which particularly high performance requirements apply (e.g. productive systems in contrast to test or development systems), it is consequently recommendable to use a mode which is very similar to native mode.
- Make as many real CPUs available to such systems as there are (in total) attached virtual CPUs in the guest systems concerned.
The result of this is that each virtual CPU has its own real CPU to use exclusively ("dedicated CPU"). This prevents unnecessary overhead resulting from avoidable cache losses and wait times for a free real CPU or multiprocessor locks.
The following configuration, for example, is suitable for this purpose:
- In addition to the standard CPU pool, configure another CPU pool for critical productive systems with dedicated real CPUs.All other guest systems use the standard CPU pool with the remaining real CPUs (or additional CPU pools which they each share).
On /390 servers, also use the VM attribute VM-ACTIVE-IDLE for VMs with dedicated CPUs.
This function prevents virtual CPUs in the wait state (idle) from leaving the real CPU. There is hardly any hypervisor overhead.
A measurement on a /390 server with 4 CPUs and only one VM showed that when dedicated CPUs and the VM attribute VM-ACTIVE-IDLE are used, the VM2000 overhead is reduced by 75% compared to when dedicated CPUs are used without the VM attribute VM-ACTIVE-IDLE.
No evaluation of the VM-ACTIVE times (/SHOW-VM-STATUS or VM report of openSM2) is possible for VMs with VM-ACTIVE-IDLE.