Performance questions
Hello, What is the most efficient way to coordinate work in a synchronous fashion between a problem state TCB and an enclave SRB? Pause, release? Wait, Post, Latch services? Other? The enclave SRB will be scheduled into the problem state TCB's address space. The enclave SRB will be parsing a buffer and searching for certain tokens. The processing is simple and does not have many lines of code, but could be executed 10s of millions of times per day. The buffer is processed in a read only manner. Thanks, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance questions
On Sun, Nov 14, 2010 at 4:02 PM, Sam Siegel s...@pscsi.net wrote: Hello, What is the most efficient way to coordinate work in a synchronous fashion between a problem state TCB and an enclave SRB? Pause, release? Wait, Post, Latch services? Other? The enclave SRB will be scheduled into the problem state TCB's address space. The enclave SRB will be parsing a buffer and searching for certain tokens. The processing is simple and does not have many lines of code, but could be executed 10s of millions of times per day. The buffer is processed in a read only manner. If both are operating synchronously in the same address space, why bother to introduce the SRB (and communication/synchronization overhead) at all? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance questions
On Sun, Nov 14, 2010 at 2:22 PM, Chris Craddock crashlu...@gmail.comwrote: On Sun, Nov 14, 2010 at 4:02 PM, Sam Siegel s...@pscsi.net wrote: Hello, What is the most efficient way to coordinate work in a synchronous fashion between a problem state TCB and an enclave SRB? Pause, release? Wait, Post, Latch services? Other? The enclave SRB will be scheduled into the problem state TCB's address space. The enclave SRB will be parsing a buffer and searching for certain tokens. The processing is simple and does not have many lines of code, but could be executed 10s of millions of times per day. The buffer is processed in a read only manner. If both are operating synchronously in the same address space, why bother to introduce the SRB (and communication/synchronization overhead) at all? Eventually, the SRB will be used to offload work to a zIIP. Otherwise I would not consider this route. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance questions
On Sun, Nov 14, 2010 at 4:30 PM, Sam Siegel s...@pscsi.net wrote: On Sun, Nov 14, 2010 at 2:22 PM, Chris Craddock crashlu...@gmail.com wrote: If both are operating synchronously in the same address space, why bother to introduce the SRB (and communication/synchronization overhead) at all? Eventually, the SRB will be used to offload work to a zIIP. Otherwise I would not consider this route. Beware of the head long rush to leverage zIIP engines. Using a zIIP is definitely NOT worth the effort unless the work you're offloading to the zIIP is a significant percentage of the total. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Rer: Performance questions
Sam Siegel wrote: begin snippet The enclave SRB will be parsing a buffer and searching for certain tokens. The processing is simple and does not have many lines of code, but could be executed 10s of millions of times per day. The buffer is processed in a read only manner. /end snippet As Chris Craddock has already implied, the important question here is not how many tens of millions of times per day this code is [to be] executed. It is the ratio of SRB management path length S (for creation, synchronization, etc.) to lower-cost ZIIP|ZAAP application path length P. If S P the approach Mr. Siegel is taking is at best unwise. Such qualitative language as simple and does not have many lines of code does not make it possible to answer this question. Path-length numbers are needed. I will, however, venture the qualitative judgment that delegating trivial tasks to an SRB in order eventually to exploit lower ZAAP|ZIIP costs is a poor idea. Focus instead on finding non-trivial work, for which P S, for them to do. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rer: Performance questions
On Sun, Nov 14, 2010 at 5:56 PM, john gilmore john_w_gilm...@msn.comwrote: Sam Siegel wrote: begin snippet The enclave SRB will be parsing a buffer and searching for certain tokens. The processing is simple and does not have many lines of code, but could be executed 10s of millions of times per day. The buffer is processed in a read only manner. /end snippet snip I will, however, venture the qualitative judgment that delegating trivial tasks to an SRB in order eventually to exploit lower ZAAP|ZIIP costs is a poor idea. Focus instead on finding non-trivial work, for which P S, for them to do. unsnip My intention is to allow the empirical results to determine the offload benefit. Different versions of the software with using the various synchronization mechanisms can be built to perform the tests. It was my intention to leverage the knowledge of the IBM-MAIN to find the most efficient one without having to code all of the variations. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance questions
You might want to look up PAUSE ELEMENTS and more specifically, IEAVXFR. The starting point is Authorized Assembler Services Guide, Chapter 4 Christopher Y. Blaicher Senior Software Developer Austin Development Lab phone: 512.340.6154 mobile: 512.627.3803 fax: 512.340.6647 10431 Morado Circle Austin, TX 78759 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Sunday, November 14, 2010 8:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Performance questions On Sun, Nov 14, 2010 at 5:56 PM, john gilmore john_w_gilm...@msn.comwrote: My intention is to allow the empirical results to determine the offload benefit. Different versions of the software with using the various synchronization mechanisms can be built to perform the tests. It was my intention to leverage the knowledge of the IBM-MAIN to find the most efficient one without having to code all of the variations. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance questions
On Sun, Nov 14, 2010 at 6:53 PM, Blaicher, Chris chris_blaic...@bmc.comwrote: You might want to look up PAUSE ELEMENTS and more specifically, IEAVXFR. The starting point is Authorized Assembler Services Guide, Chapter 4 Thanks ... I will look at that service. Cheers, Sam Christopher Y. Blaicher Senior Software Developer Austin Development Lab phone: 512.340.6154 mobile: 512.627.3803 fax: 512.340.6647 10431 Morado Circle Austin, TX 78759 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Sunday, November 14, 2010 8:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Performance questions On Sun, Nov 14, 2010 at 5:56 PM, john gilmore john_w_gilm...@msn.com wrote: My intention is to allow the empirical results to determine the offload benefit. Different versions of the software with using the various synchronization mechanisms can be built to perform the tests. It was my intention to leverage the knowledge of the IBM-MAIN to find the most efficient one without having to code all of the variations. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Real storage usage increase in z/OS 1.11
Hallo Ricc, you should check Apar OA32170 which deals with increased real storage usage for hash tables used for list structures. Kind regards, Horst Schivelbein (Heaven ain't bad but you don't get nothing done...) T-Systems International GmbH Großkunden Horst Schivelbein OSCO-T1 Nauheimer Strasse 98,D- 70372 Bad Cannstatt +49 711-555- 44663 (Phone) +49 171 76 15791 (Mobile) E-mail: horst.schivelb...@t-systems.com Internet: http://www.t-systems.com/ mailbox: osco...@t-systems.com T-Systems International GmbH Supervisory Board: René Obermann (Chairman) Board of Management: Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, Georg Pepping, Klaus Werner Commercial register: Amtsgericht Frankfurt am Main HRB 55933 Registered office: Frankfurt am Main WEEE-Reg.-No. DE87523644 Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. Big changes start small - conserve resources by not printing every e-mail. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
