On 5/09/2023 10:13 pm, Peter Relson wrote:
I don't think that that is a correct conclusion. It is far more complicated than thinking that this is simply about one LPAR. It depends what your logical vs physical configuration is. It depends what resources your other LPARs need. And a lot more.
I understand that this is designed to manage the dispatching between multiple LPARs. However, if the result is that experts advise to "only use SMT when [adding real zIIPs] was not (or no longer) feasible" and "not enable SMT until you have a defined reason to and where it's then proven to be beneficial", and customers are commonly seeing workloads degraded by enabling SMT, I'm not sure that the objectives are being achieved.
Considering the interactions wth other LPARs, is there a significant difference between using the same dispatching pattern for SMT-2 as SMT-1 until all CPUs are busy, versus disabling SMT-2 completely?
SMT should be all gravy. It's supposed to be extra capacity, and ideally undetectable until you hit the limits without SMT.
And it is expected that zIIPs are not run "consistently 100% busy". That would not be an appropriate usage of zIIPs.
Why not? Is WLM unable to manage dispatching priorities for zIIP? I know a lot of zIIP work is short transactions like DDF, but there's also Java, which is great for CPU intensive work. Java has functions that will check how many CPUs the system has, and parallelize work onto N-1 threads. It's a bit antisocial on z/OS I know, but that's what WLM is for. That would definitely drive zIIPs to 100%, potentially for extended periods.
-- Andrew Rowley Black Hill Software ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
