Re: Question on PR/SM dispatcher
Shane ibm-m...@tpg.com.au wrote in message news:20111220123112.2a437a52@xpfs... On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote: PR/SM dispatches Logical CPs not Logical Partitions. I wonder if it'd be considered churlish to point out this wasn't always the case. Shane ... Shane, - what is churlish, I can't find an understandable translation. - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls MDF dispatched entire domains (their word for lpar). Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
A churl is a very old word for a peasant or free man. But became to be used for someone who has no manners or breeding. To be churlish is to have bad manners. Like telling a new mom: That is one ugly baby! http://en.wikipedia.org/wiki/Churl quote This meaning held through the 15th century, but by then the word had taken on negative overtone, meaning a country person and then a low fellow. By the 19th century, a new and pejorative meaning arose, one inclined to uncivil or loutish behaviour. /quote -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Tuesday, December 20, 2011 2:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question on PR/SM dispatcher Shane ibm-m...@tpg.com.au wrote in message news:20111220123112.2a437a52@xpfs... On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote: PR/SM dispatches Logical CPs not Logical Partitions. I wonder if it'd be considered churlish to point out this wasn't always the case. Shane ... Shane, - what is churlish, I can't find an understandable translation. - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls MDF dispatched entire domains (their word for lpar). Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
In ce3ffbb7e42033469ef752a1d8a19ba1eef...@kl1221tc.cs.ad.klmcorp.net, on 12/19/2011 at 09:29 AM, Vernooij, CP - SPLXM kees.verno...@klm.com said: You don't have to wait for it, you can also force it. Amdahl's MDF did it. The main difference was that PR/SM is interrupt driven and MDF was timeslice driven. How did MDF detect the end of a timeslice if not by an interrupt? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Are you serious? Kees. Shmuel Metz , Seymour J. shmuel+ibm-m...@patriot.net wrote in message news:20111220144901.d5dcaf58...@smtp.patriot.net... In ce3ffbb7e42033469ef752a1d8a19ba1eef...@kl1221tc.cs.ad.klmcorp.net, on 12/19/2011 at 09:29 AM, Vernooij, CP - SPLXM kees.verno...@klm.com said: You don't have to wait for it, you can also force it. Amdahl's MDF did it. The main difference was that PR/SM is interrupt driven and MDF was timeslice driven. How did MDF detect the end of a timeslice if not by an interrupt? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Chaucer spelt it cherl. Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu, Date: 20/12/2011 13:10 Subject: Re: Question on PR/SM dispatcher Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu A churl is a very old word for a peasant or free man. But became to be used for someone who has no manners or breeding. To be churlish is to have bad manners. Like telling a new mom: That is one ugly baby! http://en.wikipedia.org/wiki/Churl quote This meaning held through the 15th century, but by then the word had taken on negative overtone, meaning a country person and then a low fellow. By the 19th century, a new and pejorative meaning arose, one inclined to uncivil or loutish behaviour. /quote -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Tuesday, December 20, 2011 2:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question on PR/SM dispatcher Shane ibm-m...@tpg.com.au wrote in message news:20111220123112.2a437a52@xpfs... On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote: PR/SM dispatches Logical CPs not Logical Partitions. I wonder if it'd be considered churlish to point out this wasn't always the case. Shane ... Shane, - what is churlish, I can't find an understandable translation. - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls MDF dispatched entire domains (their word for lpar). Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
In ce3ffbb7e42033469ef752a1d8a19ba1eef...@kl1221tc.cs.ad.klmcorp.net, on 12/20/2011 at 04:15 PM, Vernooij, CP - SPLXM kees.verno...@klm.com said: Are you serious? Certainly. If I recall correctly, MDF was implemented in what Amdahl called macrocode, not by dedicated hardware. So what triggered the redispatch at the end of a time slice if not an external interrupt? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Of course, but I suppose you know what I meant: PR/SM sits waiting for an LPAR to produce an interrupt and decides then what to do next. MDF determines that it wants to take action after a certain timeslice, whether the domains like it or not. The fact that the end of the timeslice might be signalled by an interrupt, nominates you for the 'sheesj of the week' posting. Kees. Shmuel Metz , Seymour J. shmuel+ibm-m...@patriot.net wrote in message news:20111220151739.9a61ef58...@smtp.patriot.net... In ce3ffbb7e42033469ef752a1d8a19ba1eef...@kl1221tc.cs.ad.klmcorp.net, on 12/20/2011 at 04:15 PM, Vernooij, CP - SPLXM kees.verno...@klm.com said: Are you serious? Certainly. If I recall correctly, MDF was implemented in what Amdahl called macrocode, not by dedicated hardware. So what triggered the redispatch at the end of a time slice if not an external interrupt? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) writes: Certainly. If I recall correctly, MDF was implemented in what Amdahl called macrocode, not by dedicated hardware. So what triggered the redispatch at the end of a time slice if not an external interrupt? the guys doing MDF use to come to baybunch and pump me for information ... I had done time-slice dispatching since my undergraduate days in the 60s and had been involved in design and implementation of ECPS for the 138/148 ... there have numerous issues over the years with implementations trying to get around use of timer-based considerations ... hoping that other events would provide sufficient control not having to resort to the additional overhead ... this has periodically resulted in monumental gafs when the various other failed to occur in the anticipated ways. the other issue was that the MDF implementation for Amdahl was significantly simpler because of the macrocode use. 3090 had to respond with pr/sm ... but that was a significantly more complex undertaking because there wasn't any equivalent facility and they had to fallback to horizontal microcode. there was also issue in the early 1980s when somebody having gotten an award for changes to mvs/xa, contacted me about whether similar changes could be made to vm. I commented that I had not done it any other way since my work as undergraduate in the 60s ... and in fact had arguments with VS2/SVS (precursor to MVS) in the early 70s about they shouldn't be doing it the wrong way. past posts mentioning part of the effort for ECPS http://www.garlic.com/~lynn/94.html#21 past posts mentioning dispatching/scheduling http://www.garlic.com/~lynn/subtopic.html#fairshare misc past posts mentioning macrocode: http://www.garlic.com/~lynn/2002p.html#44 Linux paging http://www.garlic.com/~lynn/2002p.html#48 Linux paging http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand? http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea http://www.garlic.com/~lynn/2005d.html#59 Misuse of word microcode http://www.garlic.com/~lynn/2005d.html#60 Misuse of word microcode http://www.garlic.com/~lynn/2005h.html#24 Description of a new old-fashioned programming language http://www.garlic.com/~lynn/2005p.html#14 Multicores http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor http://www.garlic.com/~lynn/2005u.html#40 POWER6 on zSeries? http://www.garlic.com/~lynn/2005u.html#43 POWER6 on zSeries? http://www.garlic.com/~lynn/2005u.html#48 POWER6 on zSeries? http://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode http://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away http://www.garlic.com/~lynn/2006j.html#32 Code density and performance? http://www.garlic.com/~lynn/2006j.html#35 Code density and performance? http://www.garlic.com/~lynn/2006m.html#39 Using different storage key's http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email http://www.garlic.com/~lynn/2006u.html#33 Assembler question http://www.garlic.com/~lynn/2006u.html#34 Assembler question http://www.garlic.com/~lynn/2006v.html#20 Ranking of non-IBM mainframe builders? http://www.garlic.com/~lynn/2007b.html#1 How many 36-bit Unix ports in the old days? http://www.garlic.com/~lynn/2007d.html#3 Has anyone ever used self-modifying microcode? Would it even be useful? http://www.garlic.com/~lynn/2007d.html#9 Has anyone ever used self-modifying microcode? Would it even be useful? http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history http://www.garlic.com/~lynn/2007k.html#74 Non-Standard Mainframe Language? http://www.garlic.com/~lynn/2007n.html#96 some questions about System z PR/SM http://www.garlic.com/~lynn/2008c.html#32 New Opcodes http://www.garlic.com/~lynn/2008c.html#33 New Opcodes http://www.garlic.com/~lynn/2008c.html#42 New Opcodes http://www.garlic.com/~lynn/2008j.html#26 Op codes removed from z/10 http://www.garlic.com/~lynn/2008r.html#27 CPU time/instruction table http://www.garlic.com/~lynn/2010m.html#74 z millicode: where does it reside? http://www.garlic.com/~lynn/2011c.html#93 Irrational desire to author fundamental interfaces -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
On Tue, 20 Dec 2011 09:14:36 -0500, Shmuel Metz wrote: How did MDF detect the end of a timeslice if not by an interrupt? That is how it detected the end of a time slice. Early MDF code would dispatch a different domain as soon as a processor entered a wait state. That was determined to cause performance problems, largely due to the effects of cache misses. By the time MDF was delivered to the field, it was changed so that a domain was allowed to run on a processor until its time slice ended. The result was improved performance. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
On Tue, 20 Dec 2011 10:33:14 -0500, Shmuel Metz wrote: If I recall correctly, MDF was implemented in what Amdahl called macrocode, That's correct. Very similar to the millicode on current IBM mainframes. A superset of 370 instructions that ran in system state. not by dedicated hardware. There was considerable hardware included in the Amdahl 580 series processors to make macrocode and MDF work. There was a separate set of registers that were available in system state. System state was a third state of operation, in addition to problem and supervisor state. There were additional instructions for referencing the domain's registers and storage. Ther was also hardware for mapping domain storage and 31-bit or 32-bit addressing. I can't remember which. This was all designed long before Extended Architecture. When IBM introduced XA, the design of the 580 allowed Amdahl to implement Extended Architecture relatively easily. There was an ALTA Principles of Operation that described the additional registers, instructions, etc. I turned in my copy of the ALTA POO when I left Amdahl, but I studied it thoroughly while I was there. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Shane ibm-m...@tpg.com.au wrote in message news:20111220123112.2a437a52@xpfs... On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote: PR/SM dispatches Logical CPs not Logical Partitions. SNIPPAGE - I am quite sure that pr/sm always dispatched Logical CPs and Amdahls MDF dispatched entire domains (their word for lpar). snippage PR/SM and LPARs are IBM's answer to MDF (Multiple Domain Facility and Domains). In fact, IBM was AMDAHL's second customer to pay for MDF. But because the machine they had wasn't ready to be field upgraded, IBM wasn't the second customer to have MDF (man, lots of memories have been awakened by this posting). Through the 5990 machines, all LPs were dispatched simultaneously in a Domain. The idea was that we did not want to cause a spin lock loop problem that would cause ACR. We also were trying to solve a problem with I/O elongation (a domain would start an I/O, lose dispatch, the I/O would complete and the interrupt would be hanging until the Domain was dispatched again). We had discussed asynchronous dispatch, but it was decided to not implement it. Then came the big layoff of 1989 just after Thanksgiving... I have no idea what happened after that as I never saw any AMDAHL machines after the 5990-1400s in any shop where I worked. I do know that IBM implemented asynchronous dispatch. When, I don't know. And the particulars I don't know. And I don't work in POK so I don't have access to the LPAR - PR/SM logic, so I honestly can't speak to that at all. Regards, Steve Thompson Staff Software Engineer Connect:Direct for z/OS IBM - Software Group (469) 524-2622 sthomp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
On Tue, 20 Dec 2011 09:19:35 +0100, Vernooij, CP wrote: I am quite sure that pr/sm always dispatched Logical CPs and Amdahls MDF dispatched entire domains (their word for lpar). If by dispatched entire domains you mean that all of the logical processors for a domain were always dispatched together, I don't think that is correct. For one thing, it would have made MDF more complicated than it needed to be. For another, it would have meant that if you had domain A with 1 LP and domain B with 2 LPs on a system with two physical processors, whenever domain A was active, one of the processors would have always been idle. That would not have been very efficient. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
In ce3ffbb7e42033469ef752a1d8a19ba1eef...@kl1221tc.cs.ad.klmcorp.net, on 12/20/2011 at 04:53 PM, Vernooij, CP - SPLXM kees.verno...@klm.com said: Of course, but I suppose you know what I meant: You're welcome to suppose what you wish. Just don't be surprised when your suppositions are wrong more often than they're right. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Shmuel Metz , Seymour J. shmuel+ibm-m...@patriot.net wrote in message news:20111220170650.bceecf58...@smtp.patriot.net... In ce3ffbb7e42033469ef752a1d8a19ba1eef...@kl1221tc.cs.ad.klmcorp.net, on 12/20/2011 at 04:53 PM, Vernooij, CP - SPLXM kees.verno...@klm.com said: Of course, but I suppose you know what I meant: You're welcome to suppose what you wish. Just don't be surprised when your suppositions are wrong more often than they're right. Yes, in this case this appears to be a good advise. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Mauri Kanter itzuv...@013.net.il wrote in message news:7558267718421282.wa.itzuviem013.net...@bama.ua.edu... Thank you Jim. Crystal Clear. Mauri, I was going to reply, that your view on pr/sm was incorrect: pr/sm does not dispatch entire LPARs, but individual processors, if the LPAR's weight allows it. But I think Jim's answers made that clear also. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
To dispatch entire LPARs would be waiting for 2n ducks to line up in a row: An event with progressively high latency in the n1 case. Which is one reason we don't do it, I guess. (The 2n ducks would be the n logicals and n physicals.) Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
You don't have to wait for it, you can also force it. Amdahl's MDF did it. The main difference was that PR/SM is interrupt driven and MDF was timeslice driven. Therefor it did not have to wait for the ducks to line up, but simply took an entire domain from the processors when its time was up and dispatched a new domain. Both had their pro's and con's and MDF lost the game, but for totally different reasons. Kees. Martin Packer martin_pac...@uk.ibm.com wrote in message news:off8674931.d52d3037-on8025796b.002d3b37-8025796b.002d6...@uk.ibm.c om... To dispatch entire LPARs would be waiting for 2n ducks to line up in a row: An event with progressively high latency in the n1 case. Which is one reason we don't do it, I guess. (The 2n ducks would be the n logicals and n physicals.) Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
PR/SM dispatches Logical CPs not Logical Partitions. So Question 1 and 2 get the same answer. Any given Logical partiton can have some logical CPs ready to run, and pther logical CPs in the WAIT state. The ready to run CP will be dispatched on a real CP when it is the highest priority Logical CP ready to run. The other CPs in the partition are not ready to run, and so are not competing for resources. The logical CP priority is the weight divided by the number of Logical CPs in the partition. In most cases PR/SM dynamically determines the run time (a.k.a. time slice) to be 12.5 ms. Most LCPs will enter wait state before the 12.5 ms is reached and will be queued for the event (usually I/O) that will make the LCP ready to run again. Time slices shorter than 12.5 ms usually only occur with very low weighted Logical Partitions, or hard capped partitions, or both. LCPs for these partitions can cause a drastic reduction in MIP rate, because the first few ms after getting dispatched usually involves many cache misses. By the time the real CP has its caches primed with the instructions and data, the short time slice ends and the LCP is returned to a queue waiting for a chance to get dispatched. Other ready to run LCPs with higher priority (Weight) will be queued before it. If a low weighted LCP is the only one ready to run, it can consume more than its weight. I wouldn't call the tracking of consumption averaging, but the accumulation of CPU time and tracking of the entitlement based on the weight is measured in seconds. regards Tom On 2011-12-19 12:00 AM, IBM-MAIN automatic digest system wrote: Date:Sun, 18 Dec 2011 09:50:33 -0600 From:Mauri Kanteritzuv...@013.net.il Subject: Question on PR/SM dispatcher Good day list I would like to understand something that is not still clear to me regarding PR/SM dispatching. Just to be clear I'm asking only about shared processors (not dedicated) and with dynamically determined time slices. I'm interested to understand the LPAR dispatching (before I understand the zVM dispatching and the Linux under VM dispatching;-) I a-priori apologize if I'm asking too many questions together. The questions are: Question 1 == Does PR/SM dispatches an LPAR only when the number of physical processors awaiting allows to dispatch all the logical processors required for an LPAR simultaneously? For example suppose my machine has 3 physical CPUs, and with 3 lpars defined as follows: LPARA 3 logical processors LPARB 2 logical processors LPARC 2 logical processors Option 1 Am I wasting a physical processor when LPARB or LPARC are dispatched? Option 2 - Or can the single physical processor left be dispatched to serve another lpar? If option 2 is the true one, are there spin-lock and loop related problems if only a subset of CPUs is dispatched by PR/SM? Option 3 - Or none of the options 1 and 2 are true and it works differently? Question 2 == Suppose that an LPAR running z/OS with 2 physical processors is dispatched. The first physical processor completed its work. The second physical processor is still burning cycles with for example the CICS QR TCB In other words, my z/OS at some moment got 2 physical CPUs but only one TCB has really work to do. Are both physical processors returned simultaneously to PR/SM or are they returned independently to PR/SM as they become idle? I mean, do the processors return one by one to the pool of available physical processors or simultaneously on an LPAR base? Question 3 == Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80 The one with weight 80 does not consume all its time slice and returns the processor(s) to PR/SM The one with weight 20 finds a way to use those cycles the other left Now the LPAR with weight 80 wants more than its weight Over which time interval are the weights averaged? Once a second? Once a minute? Not averaged at all? Thanks in advance for your help. Mauri. -- Tom Russell “Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear “... and remember to leave good news alone.” — Gracie HeavyHand -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote: PR/SM dispatches Logical CPs not Logical Partitions. I wonder if it'd be considered churlish to point out this wasn't always the case. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Question on PR/SM dispatcher
Good day list I would like to understand something that is not still clear to me regarding PR/SM dispatching. Just to be clear I'm asking only about shared processors (not dedicated) and with dynamically determined time slices. I'm interested to understand the LPAR dispatching (before I understand the zVM dispatching and the Linux under VM dispatching ;-) I a-priori apologize if I'm asking too many questions together. The questions are: Question 1 == Does PR/SM dispatches an LPAR only when the number of physical processors awaiting allows to dispatch all the logical processors required for an LPAR simultaneously? For example suppose my machine has 3 physical CPUs, and with 3 lpars defined as follows: LPARA 3 logical processors LPARB 2 logical processors LPARC 2 logical processors Option 1 Am I wasting a physical processor when LPARB or LPARC are dispatched? Option 2 - Or can the single physical processor left be dispatched to serve another lpar? If option 2 is the true one, are there spin-lock and loop related problems if only a subset of CPUs is dispatched by PR/SM? Option 3 - Or none of the options 1 and 2 are true and it works differently? Question 2 == Suppose that an LPAR running z/OS with 2 physical processors is dispatched. The first physical processor completed its work. The second physical processor is still burning cycles with for example the CICS QR TCB In other words, my z/OS at some moment got 2 physical CPUs but only one TCB has really work to do. Are both physical processors returned simultaneously to PR/SM or are they returned independently to PR/SM as they become idle? I mean, do the processors return one by one to the pool of available physical processors or simultaneously on an LPAR base? Question 3 == Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80 The one with weight 80 does not consume all its time slice and returns the processor(s) to PR/SM The one with weight 20 finds a way to use those cycles the other left Now the LPAR with weight 80 wants more than its weight Over which time interval are the weights averaged? Once a second? Once a minute? Not averaged at all? Thanks in advance for your help. Mauri. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Great questions. I have no idea of the answers, but will be very interested to see them! On Sun, Dec 18, 2011 at 10:50 AM, Mauri Kanter itzuv...@013.net.il wrote: Good day list I would like to understand something that is not still clear to me regarding PR/SM dispatching. Just to be clear I'm asking only about shared processors (not dedicated) and with dynamically determined time slices. I'm interested to understand the LPAR dispatching (before I understand the zVM dispatching and the Linux under VM dispatching ;-) I a-priori apologize if I'm asking too many questions together. The questions are: Question 1 == Does PR/SM dispatches an LPAR only when the number of physical processors awaiting allows to dispatch all the logical processors required for an LPAR simultaneously? For example suppose my machine has 3 physical CPUs, and with 3 lpars defined as follows: LPARA – 3 logical processors LPARB – 2 logical processors LPARC – 2 logical processors Option 1 – Am I wasting a physical processor when LPARB or LPARC are dispatched? Option 2 - Or can the single physical processor left be dispatched to serve another lpar? If option 2 is the true one, are there spin-lock and loop related problems if only a subset of CPUs is dispatched by PR/SM? Option 3 - Or none of the options 1 and 2 are true and it works differently? Question 2 == Suppose that an LPAR running z/OS with 2 physical processors is dispatched. The first physical processor completed its work. The second physical processor is still burning cycles with for example the CICS QR TCB In other words, my z/OS at some moment got 2 physical CPUs but only one TCB has really work to do. Are both physical processors returned simultaneously to PR/SM or are they returned independently to PR/SM as they become idle? I mean, do the processors return one by one to the pool of available physical processors or simultaneously on an LPAR base? Question 3 == Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80 The one with weight 80 does not consume all its time slice and returns the processor(s) to PR/SM The one with weight 20 finds a way to use those cycles the other left … Now the LPAR with weight 80 wants more than its weight … Over which time interval are the weights averaged? Once a second? Once a minute? Not averaged at all? Thanks in advance for your help. Mauri. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Question 1 == Does PR/SM dispatches an LPAR only when the number of physical processors awaiting allows to dispatch all the logical processors required for an LPAR simultaneously? No. For example suppose my machine has 3 physical CPUs, and with 3 lpars defined as follows: LPARA ? 3 logical processors LPARB ? 2 logical processors LPARC ? 2 logical processors Option 1 ? Am I wasting a physical processor when LPARB or LPARC are dispatched? Option 2 - Or can the single physical processor left be dispatched to serve another lpar? If option 2 is the true one, are there spin-lock and loop related problems if only a subset of CPUs is dispatched by PR/SM? Option 2, and yes, there can be cases where a dispatched logical processor can be spinning for a resource held by a logical processor which is not dispatched. z/OS detects this situation and informs LPAR. Question 2 == Suppose that an LPAR running z/OS with 2 physical processors is dispatched. The first physical processor completed its work. The second physical processor is still burning cycles with for example the CICS QR TCB In other words, my z/OS at some moment got 2 physical CPUs but only one TCB has really work to do. Are both physical processors returned simultaneously to PR/SM or are they returned independently to PR/SM as they become idle? I mean, do the processors return one by one to the pool of available physical processors or simultaneously on an LPAR base? Logical processors are dispatched and returned independently. Question 3 == Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80 The one with weight 80 does not consume all its time slice and returns the processor(s) to PR/SM The one with weight 20 finds a way to use those cycles the other left ? Now the LPAR with weight 80 wants more than its weight ? Over which time interval are the weights averaged? Once a second? Once a minute? Not averaged at all? LPAR calculates the share for each partition based on the weights of all of the active partitions. For a partition which is not in hiperdispatch mode, the share is distributed evenly among its logical processors. A logical processor which has not used its share is given some amount of dispatching preference over logical processors which have used more than their share. I don't know the time intervals over which the calculations are made. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
Thank you Jim. Crystal Clear. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
