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
