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 <[email protected]> wrote: > On Wed, 30 Aug 2023 12:14:29 +0000, Peter Relson [email protected] 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
