There are two levels of dispatching here: PR/SM dispatches zIIP cores for the LPARs to use. Whether the LPAR uses both threads on that core or not depends on the z/OS setting. With SMT enabled, it looks like you have twice as many zIIPs as the LPAR has online zIIP cores. But (IIRC) the even-odd pairs are really two threads on the same zIIP core.
So for example, a z/OS LPAR has two zIIPs online. (Maybe you paid for 3 zIIPs and you give 2 logical zIIPs to each LPAR on the HMC). With SMT enabled and active, that will show up as 4 zIIPs. zIIPs 0 and 1 are threads 0 and 1 on the a zIIP core and zIIPs 2 and 3 are threads 0 and 1 on a second zIIP core. At any given point in time, PR/SM will have dispatched 0 to 2 zIIP. So pretend that at this moment in time PR/SM has given 2 cores to the LPAR, so from z/OS's perspective there are 4 zIIPs to dispatch work on. If there are two units of work to run on the zIIP, those units of work will likely go to zIIPs 0 and 1 which are the two threads on the one zIIP core (densely packing work to that core) vs. putting the work on zIIPs 0 and 2 which are different zIIP cores (sparsely packing the work on those cores). In real life things are of course more chaotic. But that's the general idea. I just presented on PR/SM and z/OS dispatching and managing of CPUs at SHARE New Orleans. If you're a SHARE member you should be able to access it from their website I believe. Hopefully we'll get it up on our website next week. Oh and why do we (mainframe) care more than the other platforms? I'd say there are multiple reasons for that: - Most other OSes sparsely pack the cores so the degradation of having multiple threads sharing the same core isn't felt as soon as when z/OS densely packs the cores. - We measure things at a finer level of detail than the other platforms (typically) do. And then we obsess over them because our individual unit costs are much higher. When a CPU core costs you a few hundred dollars your need to worry about the fine details of optimizing the usage of that resource decreases significantly. (Now in aggregate they may spend more to do the same amount of work because they have to buy so many more cores, but... I think the point remains that you don't worry so much about individual core performance. Although maybe they should!) - On your own PC/laptop it matters relatively little and at this point in time, people may just assume it's "ok" there and so is "ok" on the server that's running somewhat similar feeling hardware. This may not be a good assumption. - Actually, when Intel's Hyper-Threading came out there were server situations where the recommendation was to disable it. I'm not sure if that's still the case or not. But I do know you can disable it if you're running (at least) bare-metal instances in AWS and a quick google shows that at least IBM cloud also allows you to disable it. So it may be that the other platforms also sometimes have valid reasons to disable it. Scott Chapman On Thu, 31 Aug 2023 13:35:11 +0000, kekronbekron <kekronbek...@protonmail.com> wrote: >Hi Scott, > >Could you expand on this please. > >> But z/OS "densely packs" the cores, meaning that if a work unit is running >> on a zIIP core and another zIIP eligible work unit comes in it will run on >> the second thread on the already busy zIIP core instead of being dispatched >> to an available but unused zIIP core. As I understand it, this was done >> because PR/SM dispatches cores, not threads, to the LPARs and this dense >> packing makes that easier. > >What does "dispatches cores" mean, and how is "run on second thread on already >busy zIIP" an example of that (dispatching cores), and the second part >(dispatch to a new core) isn't? > > >Also a general Q to all - why is SMT a big topic with mainframes? >Distributed's hyperthreading is everywhere. > >- KB > >------- Original Message ------- >On Thursday, August 31st, 2023 at 18:20, Scott Chapman ><000003fffd029d68-dmarc-requ...@listserv.ua.edu> wrote: > > >> On Wed, 30 Aug 2023 12:14:29 +0000, Peter Relson rel...@us.ibm.com wrote: >> >> > I'll bite. Why would you want to switch? Activating it is one thing. >> > >> > There are situations where a job might run better not multi-threaded. >> > It's not clear that the system ever would run better not multi-threaded. >> >> >> There are multiple considerations as to whether SMT should be enabled. As Ed >> Jaffe said, my preference would be to add real zIIPs if I at all could and >> only use SMT when that was not (or no longer) feasible. My recommendation is >> to not enable SMT until you have a defined reason to and where it's then >> proven to be beneficial. >> >> As a review for those stumbling across this who might not know: >> If there's only single unit of work running on the zIIP, SMT matters not at >> all because there's no contention for that zIIP core. But when there's two >> active threads on a zIIP, both will contend for the common core resources >> and so run somewhat slower. So it is never a single job that runs worse >> multi-threaded, if SMT is negatively impacting individual workloads it will >> always be impacting work in groups of two work units. >> >> But z/OS "densely packs" the cores, meaning that if a work unit is running >> on a zIIP core and another zIIP eligible work unit comes in it will run on >> the second thread on the already busy zIIP core instead of being dispatched >> to an available but unused zIIP core. As I understand it, this was done >> because PR/SM dispatches cores, not threads, to the LPARs and this dense >> packing makes that easier. >> >> So depending on the arrival pattern and volume of the work, how busy the >> zIIPs are, what the LPAR configuration is like, etc. it is possible that >> work could be densely packed on the zIIPs while there's unused zIIP cores >> that would allow the work to run better. zIIPs are often lowly utilized >> compared to GCPs and at certain points in time, it's entirely conceivable >> that it would be better to utilize under-utilized zIIP cores without SMT. >> >> In general, SMT is more valuable at higher zIIP utilization levels. However >> (depending on lots of things) it can be useful at lower utilizations where, >> for example, there's spikes in the arrival patterns of very short-running >> transactions. That can certainly happen in DDF environments, but the most >> egregious cases of this I've seen have been in Websphere environments. >> >> The threshold for "at higher zIIP utilization levels" is variable again >> depending. E.G. in a configuration with low zIIP utilization levels where >> there's only 1 or 2 zIIPs shared amongst several LPARs, SMT might be useful >> because an LPAR may not have access to both zIIP cores simultaneously so >> having that extra thread on the single core that PR/SM gave it could be >> useful. >> >> Another, less significant, consideration is capacity planning. Because >> performance and zIIP consumption is so variable with SMT enabled and because >> the workloads' zIIP consumption in the SMF 30 and SMF 72 records are >> recorded as an estimate of what they would have consumed if SMT was not >> enabled, accurate zIIP capacity planning (especially at the workload level) >> is pretty much impossible with SMT enabled. But this is of relatively little >> concern if your zIIP capacity planning is "we'll buy more when we start to >> see problems... or when we do the next upgrade". Which, to be fair, most >> customers are in that situation: they don't do any real detailed planning >> for zIIP capacity. >> >> Scott Chapman >> >> ---------------------------------------------------------------------- >> 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
