>... however, we were warned that 'some customers' were experiencing serious >performance problems when zIIP eligible work spilled over to general CPs.
Yeah, that is what I read and hear also, and I have no reason not to believe it. In fact, I suspect we've just been bitten by zIIP overload. However, this is not at the level of technical detail I'm seeking to understand. >The reason, we were told, was that while general CP management had evolved >over the decades with a huge boatload of OS code to handle contention, zIIPs >were newcomers that were more or less on their own in playground competition. >The wiry little guys with little bully protection. Huh? Do you want to say you've been told that zIIP management (dispatcher and WLM/SRM) is new code that is distinct from the CP management (dispatcher and WLM/SRM) code? I must be misunderstanding you. zIIPs are general purpose processors exactly the same as CPs are, aren't they. They will run whatever work unit happens to be found on their dispatcher queue, don't they? The decision which work queue to chain a newly ready work unit on is made at queueing time. It is just an (not really) arbitrary decision that IBM chose only enclave SRBs are eligible to be queued on the zIIP WUQ. The only new thing is that the dispatcher, when running on a zIIP, may ask, i.e. flag a CP to also look for work on the zIIP WUQ. And it is the dispatcher, when running on that CP, which looks at both WUQ to select the next work unit to dispatch. This is how I think it works. Tell me, anyone, if this is not correct. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
