When Good Work Doesn't Go To zIIP / zAAP Heaven
MartinPacker 11000094DH Visits (2609)
Whenever I talk about zIIPs and zAAPs I'm reminded of Zip Zap miniature radio-controlled cars. But (to get past the censors I have to say) zIIPs and zAAPs are not toys.
Here's an extract from a post on MXG-L that Bernie Pierce made. (I reproduce it with his kind permission.)
If there is contention for the local lock, the cross memory local lock, the CMS lock or any other suspend lock, units of work that are zAAP or zIIP eligible will be dispatched on a standard processor as they are given the lock in periods of contention for the lock. When the lock is available, this processing does not apply; it applies only when the requestor is deferred due to lock unavailable. This overrides the IFAHONORPRIORITY=NO option. In extreme cases this may be an indication of possible scalability issues if the MIPS consumed by the application are expected to increase significantly in the future. One application I examined recently had so much local lock contention that one third of the zAAP eligible time was consumed on CPs with IFAH
The customer asking the question to which Bernie responded obviously had 2-3% of the eligible work running on general-purpose engines (GCPs).
I think it's worthwhile tracking this with the appropriate SMF 72 (Service-Class level) and SMF 30 (Address-Space level) instrumentation - but not to be too paranoid about it. It's another example of where you need to dig below the marketing material to understand what's really going on. And, through the life of zIIPs and zAAPs we'll all learn a lot more about how they work and how work is scheduled on them.
A comment that may get me in trouble: The way zIIPs and zAAPs work has gotten complicated (to my mind) to the extent that I wonder how many people really know what's going on and how to manage them.
The state of the art evolves... I'm told that if there were (hypothetically) to be a similar control to IFAHONORPRIORITY for zIIPs , the same considerations would apply to zIIP when NO is selected as for zIIPs.