Relating Parked Time To Cores

In Drawers And More I mentioned Parking with the words

One day I’ll be able to colour VL’s according to whether they are parked or not – or rather fractions of the interval they’re parked. That’s a not very difficult fix for the python code.

Well, that proved as simple as I thought. So, along the way I built on the Parked Time numbers to get a Core-Level view of parking. The point of this post is to tell you how to do it – using SMF 70 Subtype 1. There are two challenges – but they’re not big ones:

• Relating threads to cores
• Calculating core level parking and unparking

Relating Cores To Threads

If you don’t have SMT-2 enabled for zIIPs it’s all very simple: The threads map one to one onto cores, in the right order.

SMT-2 is the more interesting case – and as the same techniques can be used for non-SMT as SMT it’s probably best to use the SMT case anyway; You might enable SMT one day.

Parked Time is recorded in the CPU Data Section – with one section per thread (CPU), not per core. The field is SMF70PAT. As I noted in Drawers And More these are only recorded for the record-cutting LPAR.

The Logical Processor Data Section has one section for each core for all LPARs on the machine.

To make sense of how a logical processor behaves – particularly its parking behaviour – you need to relate the two.

Fortunately, when SMT-2 was introduced RMF added a Core Data Section. Again, this is only for the record-cutting LPAR. But that suffices for our purposes.

This section has, among other things, the following information:

• The Core ID
• The number of CPU Data Sections to skip over to get to the first one for this core.
• The number of CPU Data Sections for this core.

My code loops over the Core Data Sections, picking up these three fields. The second field points to the first CPU Data Section for this core.

Whether the number of CPU Data Sections for this core is 1 or 2, the technique for handling Parked Time is the same.

Calculating Core Level Parking

I’m interested in how much of the RMF interval the core is parked and how much it is unparked.

First, I need the RMF Interval Duration. While it usually is 15 minutes (Or 900 seconds) it often isn’t:

• Some customers choose a different interval, perhaps 10 or even 5 minutes. \ For benchmarking you might even choose 1 minute.
• There are other sets of circumstances where the interval is cut short, such as starting and ending System Recovery Boost boost periods.

SMF70INT is the field that gives the RMF Interval Duration.

I work in seconds, by the way. Converting SMF70INT to seconds, and STCK values to seconds isn’t difficult in REXX (or Assembler).

Having listed the CPU Data Sections for a core I sum up the Parked Time for each such section and divide by the number of sections. This gives the average parked time for each thread of the core.

I’ve seen very slight differences between the parked times for each thread of a SMT-2 core – though my test data consists entirely of “all parked” or “all unparked” cores. These slight differences make me want to average rather than assuming the two threads have the same parked time. In any case my CSV file records both threads’ parked times.

I divide the parked time by the RMF interval duration to get a parked time fraction. I obviously can subtract that from 1 to get the unparked time fraction.

Conclusion

Plotting Parked Fraction and Unparked Fraction as two series, instead of just counting the Vertical Low (VL) cores did prove useful. It visually confirmed the VL’s off in another drawer were parked for the whole of the interval. So no actual cross-drawer behaviour occurred.

And now I can show it to a customer.

If I do get to open source this code all the above will have been done in the code.

And it does – as SMF70PAT is only available for the record cutting LPAR – reinforce how essential it is to cut SMF 70-1 records on all z/OS LPARs.

Making Of

I started the week writing a blog post on the way to Istanbul. Talking to my Turkish customers reinforced my view this stuff has value – and how lucky we are that z16 introduced it. (It also made me think I need to explain drawers and cache hierarchy better in every engagement where I discuss CPU. So I’m going to inject some educational material into my workshop slides.) So here I am on a plane back from Istanbul writing this follow-on piece – as I was inspired to make further progress on this project.

My open-minded view is my journey with this data will continue…