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 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.
Very interesting, I can see how that would cause problems.
It seems like an attempted optimization that actually causes problems in
the real world i.e. anyone not already running zIIPs at 100%.
The solution seems simple - IBM could change the dispatching to work
exactly the same for SMT-1 and SMT-2, until a work unit would have to
wait. Then instead of waiting it gets dispatched as a second thread.
Maybe you lose a few % at the top end, but it becomes something the
customer can turn on and use without analysis.
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?
--
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
