IBM z13 and later machines can make zIIP processors present themselves to operating systems as multiple threads per CPU if z/OS is run with the PROCVIEW=CORE parameter, called “SMT2 mode". This adds more complexity to using and understanding zIIP processor usage as not only now are you having to compare it to CP usage with the CP potentially running at a lower power, but with zIIP in CPU mode against zIIP CPU in CORE mode.
IBM state all zIIP measurements are as if the system was in “SMT1 mode", that is, as if SMT were not turned on. This means that CPU times recorded when CORE mode is in effect can be greater than expected.
This is an example of various CPU times in seconds for one RMF interval:
|
The WLM time is significantly greater than the time recorded by the LPAR.
A number of additional metrics provided by IBM can be used to interpret this including the Capacity Factor (CF) and the Maximum Capacity Factor (MCF) by CPU type.
What Acquire does is use the zIIP MCF to divide down the WLM time if in CORE mode. The value of the zIIP MCF was 1.488 for this sample interval, so the zIIP time was adjusted to 2060.22/1.488 = 1384.55. The difference of 103.37 is taken as the overhead time. This means values fit neatly into the Syncsort Capacity Management “charged” and “uncharged” metrics and also fits with what IBM’s RMF Post Processor reports in this situation.
SMT-related metrics are stored by Syncsort Capacity Management for Capacity Factor, Maximum Capacity Factor, and Thread Density, and are now available for zAAP and zIIP engines, as well as for CP engines, and ready for when IBM starts to populate those metric fields.