Dave, I'm not sure of the mechanism. I'm almost certain the Lynn Wheeler knows, however. Perhaps he will answer. Whatever the mechanism is, I'm fairly certain that the z/OS system is unaware, except for timing issues and performance degradation due to cache and TLB and ALB purges.
Tom Harper IMS Utilities Development Team Neon Enterprise Software Sugar Land, TX -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Day Sent: Monday, February 04, 2008 3:00 PM To: [email protected] Subject: Re: CPU time differences for the same job snip and can occur for other LPARs when the hyper-visor interrupts the processor to dispatch another LPAR. snip Tom, What interrupt does the executing TCB/SRB experience when the above ocurrs? Just curios as to the mechanism used to switch a processor from one LAPR to another? --Dave Day ----- Original Message ----- From: "Tom Harper" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, February 04, 2008 2:33 PM Subject: Re: CPU time differences for the same job > Tom, > > Yes, you are missing something here. Others have mentioned it, but I > will mention it again: Modern processors make extensive use of > multi-level cache. When not interrupted, the cache does a great job of > improving the performance of the processor by pre-fetching instructions > and data post-storing results. The key words here are "not interrupted". > Interruptions can occur for normal interrupts in this z/OS system, such > as I/O completing, etc., and can occur for other LPARs when the > hyper-visor interrupts the processor to dispatch another LPAR. Dedicated > LPARs can remove those types of interrupts. But this is exactly the > point: the job mix on this LPAR and other processors can and do affect > CPU times significantly. > > Another fact not well understood is the magnitude of performance > degradation when a cache miss occurs. Bob Rogers at the last SHARE > mentioned that while cache misses in first and second-level caches were > not too bad, cache misses that resulted in actual references to memory > could be as much as 600 times slower. His comment: It's almost like > doing an I/O to reference main storage compared to getting a hit in > first-level cache. > > You may want to read up on this in the IBM systems journal: > > http://www.research.ibm.com/journal/rd51-12.html > > Tom Harper > IMS Utilities Development Team > Neon Enterprise Software > Sugar Land, TX > > Tom Kelman wrote: > > Am I missing something here? Miklos is asking about the difference in > CPU time between two runs of the same job step. I would think that if > the same program was processing the same data in the same way the CPU > time should be close to consistent. Maybe not exactly the same but > there shouldn't be "several times another". Now the elapsed time could > vary widely depending on the contentions that Tom has mentioned above. > > > Tom Kelman > Commerce Bank of Kansas City > (816) 760-7632 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
