A previous poster wrote: > siis% is number of instructions that suffered SIIS in a given period
But I wonder about this. The percentage in "SIIS percentage" technically isn't a percentage of instructions, but rather percentage regarding the source of L1 i-cache directory writes. Looking at how SIIS percentage is calculated* on the z15 shows that it's: E164 / B2 * 100% where: E164: Extended counter 164 B2: Basic counter 2 Extended counter 164: Counter 164 – A directory write to the Level-1 Instruction cache directory where the returned cache line was sourced from an On-Chip Level-3 cache with intervention. Basic Counter 2: Level-1 I-cache directory-write count ... so the percentage deals with how often the L1 i-cache had to be refreshed from L3, indicating a possible SIIS violation with the thought that it's because the i-cache had to be refreshed because it was changed. Correlating this down to the "number of instructions that suffered SIIS" looks like it could be plausible from a high-level perspective, but I'm not sure. If an instruction stalls out because of its L1 i-cache line having to be refreshed, then it seems like this would correlate, but with all that happens in the pipeline, it just doesn't feel like this would always correlate 1:1. I'm thinking of things like when cache lines are pre-fetched. If during pre-fetch, a cache line had to be sourced from L3 because it changed since its last use, then (since that happens ahead of time) one particular instruction couldn't be singled out as suffering from the refresh from L3. Like I mentioned at the start of the post, I'm not saying this is straight up wrong, I just wonder about it. Source: https://www.ibm.com/support/pages/system/files/inline-files/Identifying%20SIIS%20Inefficiency%20by%20Using%20CPU%20MF%20Counters%20slides%20Updated%20May%202022_0.pdf =============================== Adam Johanson Broadcom Mainframe Software Division ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
