(Originally posted 2015-11-30.)
In IRD And Hiperdispatch – Wrong ’Em Boyo I briefly mentioned the concepts of Parking and Unparking. It wasn’t appropriate to cover them in depth there. So I’ll talk about them now, focusing on the RMF instrumentation.
But first a brief discussion on Parking versus IRD Logical Processor Management.
Hiperdispatch doesn’t vary logical processors online and offline. SMF70ONT will show each engine online for the whole interval. Instead it parks and unparks them, with a parked engine selecting no work to run.
The data that describes parking is in SMF 70 but not in the Logical Processor Data section. Instead it’s in the CPU Data section.
Why Does What Section It’s In Matter?
It’s because some SMF 70 sections are PR/SM-originated and some related only to this z/OS system. The parking-related data is in a section that is in the latter category.
This means to understand Hiperdispatch parking and Unparking you need to collect SMF 70 data from all significant systems. Our reporting takes data from all systems from which it’s generated, and yours should too.
So What Is This Data?
For parking it’s one field: SMF70PAT, described here:
So, a logical processor that is online but parked will show
- A full interval’s worth of Online Time in SMF70ONT.
- A full interval’s worth of Parked Time in SMF70PAT.
If you draw the two data sources together you can make sense of parking, particularly if you understand the Polarization picture (described in IRD And Hiperdispatch – Wrong ’Em Boyo)
And believe me our code in this area has got very complex. 🙂 And it’s going to get more complex soon… 🙂
Early on IRD would vary low-numbered logical processors offline first – which wasn’t great for handling I/O interrupts. Then it changed to the high-numbered processors first. ↩
In fact since drafting this yesterday a couple of nice little tweaks went in. 🙂 ↩