I found a youtube video of the GSE presentation: https://www.youtube.com/watch?v=WAjMr4q4lUk
Slide 10 contains the topic. It's not fully clear what "system does mean". Refer is to the multiprocessor factor that should be related to CEC configuration and at the same time talks about adding a processor to a member that should be related to LPAR configuration. If we refer to CEC configuration, it should lead me to think that it's better to have more small physical machines (with 8 processors ?), which means I need 8 3931-708 CECs to raise 100K Mips. It does not seem so cheap and doesn't fully explain why IBM builds CEC with 200 processors. So, in a real configuration with two CECS and N LPARs, Data Sharing, some partitions with more than 12 GPs + 8 zIIPs, would it be better to add a couple more partitions with less GPs and zIIP ? Polarization is OK. Does there exist a factor (I mainly think to WLM and dispatcher) that can be so stressed in managing such a number of processors and processes ? Is there any advantage in lowering the number of processes per LPAR ? Best regards. Max <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Privo di virus.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> Il giorno sab 20 apr 2024 alle ore 11:34 Graham Harris < 000005dd2d4999ec-dmarc-requ...@listserv.ua.edu> ha scritto: > "It doesn't take an extremely large number of CPUs > before a single-image system will deliver less capacity than a sysplex > configuration of two systems, each with half as many CPUs". > > In the original context of the GSE material, does "system" here mean > physical CEC, or LPAR? > > It is unclear, and "It matters". > > For LPAR setup on a single CEC, in my view, the less LPARs the better > (although there may well be some "crossing point" with extremely large > numbers of CPUs, but have no experience of any differential comparisons to > be able to comment. zPCR may give a clue, maybe). > Much more chance of maximising High polarity LPs and thus letting > Hiperdispatch do what it is there to do, which, by design, maximises > efficiency. > > We have smallish CECs for our Development which have loads of LPARs and > with the significantly bigger engine sizes these days, even on 5xx models, > we struggle to get any High polarity LPs on any LPAR. Which is not good. > I have requested consideration of an "inbetween" hardware level between 4xx > & 5xx, as the uniprocessor size gap is now just so huge on z16. But am not > holding my breath. > > > > On Sat, 20 Apr 2024 at 09:52, Colin Paice < > 0000059d4daca697-dmarc-requ...@listserv.ua.edu> wrote: > > > IBM provides tables of the cpu available with different processors and > > different numbers of engines. Search for LSPR > > < > > > https://www.ibm.com/support/pages/ibm-z-large-systems-performance-reference > > >. > > > > https://www.ibm.com/support/pages/ibm-z-lspr-itr-zosv2r4#ibmz16A02 > gives > > 1 CPU 13 MSU > > 2 25 > > 3 37 > > 4 48 > > 5 59 > > 6 69 > > > > So one system with 6 CPU has 69 MSU .. 6 systems each with one CPU has > 78 > > MSU > > > > Part of this is serialisation of data. If two CPUs want to access the > same > > piece of real memory they interact. In simplistic terms the microcode > may > > have to go to a different physical chip to ensure only one processor is > > using the RAM. If the two CPUs are adjacent on a chip, it is faster. > > > > We had multiple threads running in an address space. We used a common > > buffer for storing trace data from the threads, and used Compare and Swap > > to update the "next free buffer". I think about 10-20 % of the total > > address space CPU was used for this CS instruction, because every thread > > was trying to get exclusive access to the field and the instruction had > to > > spin waiting for the buffer. The more CPUs the more spin - and so less > > CPU available for productive work.. > > We solved the problem by giving each thread its own trace buffer and > merged > > these when processing the dump. This hotspot simply disappeared > > Colin > > > > > > > > On Fri, 19 Apr 2024 at 09:33, Massimo Biancucci < > > 000005a019256424-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Hi everybody, > > > > > > In a presentation at GSE I saw a slide with a graph about the advantage > > of > > > having more small sysplex LPARs versus a bigger one. > > > So for instance, it's better to have 5 LPARs with 4 processors than one > > > with 20. > > > > > > There was a sentence: "It doesn't take an extremely large number of > CPUs > > > before a single-image system will deliver less capacity than a sysplex > > > configuration of two systems, each with half as many CPUs". > > > And: "In contrast to a multiprocessor, sysplex scaling is near linear. > > > Adding another system to the sysplex may give you more effective > capacity > > > than adding another CP to an existing system." > > > > > > We've been told (IBM Labs, it seems) that a 4 ways DataSharing with 8 > > CPUs > > > perform 20% better than a single LPARs with 32 CPUs. > > > The same (at another customer site) with "having more than 8 CPUs in a > > > single LPAR is counterproductive". > > > > > > Putting these infos all together, it seems it's better to have more > small > > > partitions (how small ???) in data sharing than, let me say, four > bigger > > > ones (in data sharing too). > > > > > > Anybody there has direct experience on doing and measuring such > > scenarios ? > > > Mainly standard CICS/Batch/DB2 application. > > > Of course I'm talking about well defined LPARs with High Polarization > > CPUs, > > > so don't think about that. > > > > > > Could you imagine and share your thoughts (direct experiences would be > > > better) about where the inefficiency comes from ? > > > Excluding HW issues (Polarization and so on), could it come from zOS > > > related inefficiency (WLM queue management) ? > > > If so, do zIIP CPUs participate in inefficiency growth ? > > > > > > I know that the usual response is "it depends", anyway I'm looking for > > > general guidelines that allow me to choose. > > > > > > Thanks a lot in advance for your valuable time. > > > Max > > > > > > < > > > > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > > Privo > > > di virus.www.avast.com > > > < > > > > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
