It seems that there is some confusion “out there” regarding the generosity factor associated with using a zIIP specialty processor… so I thought I’d try to clarify things in today’s blog entry.
For those unacquainted with specialty processors, you really should take some time to learn a bit more about them before you read on here. If you are interested, you can find a nice introductory piece here on my blog. At any rate, when you activate your zIIP processor, some percentage of the relevant workload can be redirected off of the main CP onto the zIIP – but not 100% of the workload. This can be frustrating for those unaccustomed to running with specialty processors. Even with zIIPs installed, all of the potential workload that could be run on the zIIP will not be redirected to the zIIP – only a percentage of it. This is what is referred to as the IBM “generosity factor.”
In order for us to comprehend generosity factor first we must define some “new” terminology: qualified and eligible work. “Qualified work” is anything that can run on the specialty processor (in this case the zIIP). “Eligible work” is anything that is actually marked as dispatchable to a zIIP. Just because work is qualified does not make it eligible.
When you are reviewing your performance reports, zIIP qualified time will be a larger number than zIIP eligible time. Qualified time is the total time which could have run on the zIIP (because it is a distributed DB2 request, XML, a parallel request, or other enclave SRB work). Eligible workload is that which IBM makes eligible to actually run on the zIIP processor. This does not mean it actually ran on the zIIP; perhaps the zIIP was running at capacity and IIPHONORPRIORITY was set to YES. In that case zIIP eligible workload can run on a general purpose CP.
The IBM generosity factor then can be calculated by dividing zIIP eligible time by zIIP qualified time. Although the IBM generosity factor is not publicly published, testing has shown it to be about 55%. (Is that generous or stingy? Maybe it should be the stinginess factor instead, huh?)
All of the above discussion really does not take into account ISV workload that gets moved to a zIIP. But, really, this type of workload doesn’t come into play when speaking about a generosity factor. ISVs that zIIP enable workload using enclave SRBs typically are not going to throttle the redirection of their workload like IBM does. Although the API provides an option to set a “generosity factor” it is uncommon for it to be set to anything other than 100 percent. Of course, that does not mean that 100 percent of the vendor product gets zIIP enabled (more on that in a moment).
When specialty processors are “in the mix,” monitoring CPU time is not as straightforward as before. The CPU your machine consumes will fall into four areas:
- General purpose CP work running on the CP
- zIIP-qualified work not marked as zIIP-eligible, so it ran on a general purpose CP. This is the work that fell outside of the generosity factor.
- zIIP-eligible work that ran on a zIIP. This is the work that actually ran on the zIIP.
- zIIP-eligible work that overflowed to a general purpose CP. This is the work that could have run on the zIIP, but did not due to capacity issues.
So What Does It All Mean?
Well, a few things spring to mind after digesting all of this. First of all, in my opinion, this whole generosity factor thing is annoying. You bought some hardware (a zIIP processor) so why can’t it be fully exploited? In other words, isn’t it reasonable to expect the generosity factor to be 100 percent, at least most of the time? Yes, yes, if the zIIP is overburdened you’ll want to avoid sending more workload to it, but other than that, why wouldn’t you want to use it at its full capacity?
I do not know of any ISV that has zIIP enabled their products and implemented a “generosity factor” of less than 100 percent using the API. But do not get confused by terminology. ISVs cannot achieve 100 percent product exploitation on zIIPs because a lot of the code cannot run in SRB mode -- that is, either too much of the functionality has already been written (and it would be too costly or difficult to re-write) or there are no SRB mode APIs to support what they want to do.
Also, keep in mind that ISVs typically pay a performance penalty due to the increased path lengths from switching back and forth between SRB and TCB mode. This can actually increase the CPU consumption of the application after things get zIIP enabled, so be careful.
Another implication of specialty processor adoption is that we need to spend a little bit more time capacity planning. You’ll need to know what the generosity factor is for all of the software you’ll be using that runs on zIIPs (and zAAPs, for that matter). Of course, the amount of work redirected to zIIPs for most system management type products will be inconsequential in the grand scheme of your overall workload.
Think about it this way: you’ve got an ISV product for loading DB2 data. The ISV has zIIP enabled the utility and that is great but… how frequently are you actually loading data into your DB2 tables? What percentage of your overall workload is that? So how much money is it actually going to save you? And it is all about saving money, isn’t it? The more you can redirect to run on specialty processors, the more money you save.
Now assume that 75 percent of your workload is DB2 related… and 15 percent of that is distributed requests, which can be redirected to zIIPs. Right off the bat you’d think that about 11.25 percent of your workload could run on the zIIP (100 x .75 x .15 = 11.25) but you’re forgetting the “generosity factor” of 55 percent which brings it down to about 6 percent. (100 x .75 x .15 x .55) 6.1875 percent.
So the bottom line here is that you should perform actual tests on your systems of any products claiming to exploit specialty processors… only then can you really determine their exploitation of specialty processors as well as any potential benefit you might gain by using them.