On 5/09/2023 9:19 pm, Scott Chapman wrote:
It's more complicated than that. Although I would agree that if an LPAR has
only a single zIIP, likely SMT would be a good idea. But B is not true for
intervals that people usually consider when looking at utilization levels
because at the level of di
Prior to those functions being zIIP-eligible they equally depended upon access
to CPU. Yet there's an unfortunately limited amount of calls for running GCPs
less busy, which would also be good for performance overall.
It's also worth noting that not all Db2 subsystems are production and don't
: IBM Mainframe Discussion List On Behalf Of
Andrew Rowley
Sent: Wednesday, September 6, 2023 6:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Switching between SMT-1 and SMT-2
==
I'm not advising customers, I&#
On 6/09/2023 7:52 pm, Martin Packer wrote:
I really hope you’re not advising customers to run the zIIP pool at 100%. Key
functions such as Db2 DBM1 Deferred Write and Prefetch, as well as Db2 Log
Writes, depend on very good access to zIIP.
I'm not advising customers, I'm just saying that work
] Re: Switching between SMT-1 and SMT-2
On 5/09/2023 10:30 pm, Martin Packer wrote:
> And “100% busy” is the wrong criterion – if you want your system to be
> performant.
Isn't that what WLM is for?
25 years ago I did a WLM conversion on a single CPU system. A single CPU
is probably the mo
Subject: [EXTERNAL] Re: Switching between SMT-1 and SMT-2
Just to provide some perspective on the value of SMT-2, critical system
functions are SMT-2 -- no choice. For example SAP runs SMT-2 on z15 (I
haven't checked for earlier models as we have z15). So SMT-2 is "so bad"
that it
Just to provide some perspective on the value of SMT-2, critical system
functions are SMT-2 -- no choice. For example SAP runs SMT-2 on z15 (I
haven't checked for earlier models as we have z15). So SMT-2 is "so bad"
that it is always used for one of the key mainframe differentiators over
other ar
On 5/09/2023 10:30 pm, Martin Packer wrote:
And “100% busy” is the wrong criterion – if you want your system to be
performant.
Isn't that what WLM is for?
25 years ago I did a WLM conversion on a single CPU system. A single CPU
is probably the most difficult to tune. By necessity, it ran at
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.
And “100% busy” is the wrong criterion – if you want your system to be
performant.
Cheers, Martin
From: IBM Mainframe Discussion List on behalf of
Peter Relson
Date: Tuesday, 5 September 2023 at 13:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Switching between SMT-1 and SMT-2
tember 2023 at 12:19
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Switching between SMT-1 and SMT-2
It's more complicated than that. Although I would agree that if an LPAR has
only a single zIIP, likely SMT would be a good idea. But B is not true for
intervals that people usually co
The current situation sounds like SMT-2 should only be used if you
a) have a single zIIP
or b) are running your zIIPs consistently 100% busy
and for b) you need to turn it off when the workload reduces?
I don't think that that is a correct conclusion. It is far more complicated
than thinking th
It's more complicated than that. Although I would agree that if an LPAR has
only a single zIIP, likely SMT would be a good idea. But B is not true for
intervals that people usually consider when looking at utilization levels
because at the level of dispatch intervals, it's much more likely there
On 31/08/2023 10:50 pm, Scott Chapman wrote:
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 unus
Those were my thoughts too.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
--- Original Message ---
On Saturday, September 2nd, 2023 at 8:42 AM, Peter Relson
wrote:
> z/O
z/OS's doing multi-threading only for zIIPs and not for standard CPs is an
implementation choice, with the challenge of accomplishing consistent and
correct chargeback data being a factor in that decision.
Peter Relson
z/OS Core Technology Design
---
On 9/1/2023 10:05 AM, Tom Brennan wrote:
Beyond that, I have no idea how this works, or what workloads could
benefit from it.
There are always things that suspend the instruction stream -- for
example a cache miss that requires a cache line be loaded from memory.
While one thread is suspe
Yes - Here's a quick blurb from some IBM doc I have on my PC:
"Simultaneous multithreading is the ability of a single physical
processor (core) to simultaneously dispatch instructions from more than
one hardware thread context. Because there are two hardware threads per
physical processor, add
There is no MT on general purpose processors. Only on zIIPs can it be enabled.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
--- Original Message ---
On Friday, September 1s
On Fri, 1 Sept 2023 at 09:55, Scott Chapman
<03fffd029d68-dmarc-requ...@listserv.ua.edu> wrote:
>
> 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 enab
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
Peter:
Hopefully you would not need to. However, since enabling SMT requires you to
re-IPL z/OS, it is nice to be able to switch from SMT-2 to SMT-1, if you are
having performance issues, without a re-IPL. I have seen very good results from
SMT-2 in my customers, but there could always be that
Mark:
Thanks. Searching through the doc I could not find this, but obviously I was
searching with the wrong terms.
Regards, Jim
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.
I was referring specifically to the thread's topic of "switching between", not
to "using" SMT-2.
I fully agree that you might choose not to use. It would be less likely that
you'd go through the hassle of "switching".
Peter Relson
z/OS Core Technology Design
--
Does the dispatcher take cache interference into account?
From: IBM Mainframe Discussion List on behalf of
Peter Relson
Sent: Wednesday, August 30, 2023 8:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Switching between SMT-1 and SMT-2
I'll bite
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 b
On Wed, 30 Aug 2023 12:14:29 +, Peter Relson 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 cons
On 30/08/2023 10:22 pm, Horne, Jim wrote:
Peter,
In theory, I agree with you. In practice, I know of at least one shop with one
system where overall throughput was worse with SMT=2 than with SMT=1 - and none
of their systems got the benefits IBM predicted. I'm not saying it's common
but it
On 8/30/2023 5:14 AM, Peter Relson 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.
It seems to me that if a shop can afford
Peter,
In theory, I agree with you. In practice, I know of at least one shop with one
system where overall throughput was worse with SMT=2 than with SMT=1 - and none
of their systems got the benefits IBM predicted. I'm not saying it's common
but it has happened.
Jim Horne
From: IBM Mainframe
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.
Peter Relson
z/OS Core Technology Design
--
Note you also must IPL PROCVIEW CORE (optionally append ,CPU_OK) in LOADxx
before you can switch back and forth by the setting in IEAOPTxx.
Scott Chapman
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send em
Create/update your IEAOPTxx member to set MT_ZIIP_MODE=1 then SET OPT=xx to
activate it.
Mark Jacobs
Sent from ProtonMail, Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
--- Original Message ---
On Tuesday,
33 matches
Mail list logo
