An important consideration when designing a SLIP trap is its possible impact on system performance. SLIP traps designed to trap abends, messages, and other software events have a fairly small risk of system performance impact as long as the targeted software event is not occurring with high frequency. However, a SLIP trap that exploits the PER hardware by monitoring instruction fetch (IF), storage alteration (SA), or successful branch (SBT) hardware events does carry a risk. If a PER SLIP trap results in an impact to system performance, the reason is the design of the trap itself. There are several considerations to take into account when designing a SLIP trap for both effectiveness and efficiency:
It is important to be aware that the protection offered by PRCNTLIM is enforced only when PER interrupts are occurring. This means that SLIP PRCNTLIM will not offer protection if a SLIP trap is enabled but inactive, or if the SLIP trap is enabled but there is no instruction execution or storage alteration within the targeted range.
Also be sensitive to the frequency with which instructions in the specified range will be executed. For more information about understanding and controlling the frequency of PER interrupts, see "Frequency of PER interrupts."
SLIP processing provides you with the power and flexibility to monitor PER events in one address space, in a set of address spaces, or even across every address space on the system. The more units of work that SLIP must monitor, the more system resource it is likely to require. Whenever practical, use the JOBNAME or ASID parameter to limit the scope of a SLIP trap. For more information about the use of these parameters, see "Special parameter considerations."
The JOBNAME and ASID parameters, optionally combined with MODE=HOME, define the cross-memory environment to be monitored by a SLIP PER trap. Certain combinations of these parameters require additional SLIP processing in order to actively monitor cross-memory activity. This additional processing begins at the time that the SLIP PER trap is enabled, and it takes place regardless of whether PER interrupts are occurring. For example, even if a SLIP PER trap is inactive (meaning that the module being monitored for instruction fetch or successful branch has not been loaded yet), it is still possible for performance to be impacted by the SLIP monitoring of cross-memory events. Fortunately, there are guidelines for designing a PER SLIP trap to minimize the overhead caused by this monitoring. These guidelines are discussed under "Special parameter considerations."
A PER trap may monitor an instruction that executes frequently, but be designed to match only when a register or data area holds a particular value. Alternatively, a PER trap may monitor an area of storage that is frequently altered, but only match when the alteration is to a specific value. On such traps, the instruction fetch or storage alteration event being monitored by the PER hardware may occur many times, only to be filtered out by the SLIP software as it processes the trap's other parameters. Although the trap is not matching, each PER interrupt represents a path through SLIP processing. For this reason, it is important to consider how frequently the hardware event that your PER trap is monitoring will occur.
Avoid monitoring instructions that are in performance paths or that are executed with a very high frequency. Avoid monitoring storage locations that are frequently updated. Avoid monitoring very large ranges unless you know that there will be a low volume of PER interrupts within that range. If such a situation is unavoidable, then strongly consider including a conservative PRCNTLIM on your PER trap to protect the system from potential impact.
SLIP SET,IF,NUCMOD=(MYCODE,0,100),A=TRACE,ID=SLP1,END
SLIP SET,IF,NUCMOD=(MYCODE,1,FF),A=IGNORE,ID=SLP2,ENDThe PER hardware will be set up to monitor instruction fetch over the entire range specified on SLP1, so a PER interrupt will occur for every instruction between offset +0 and +100 in module MYCODE. SLIP software, which receives control under the PER interrupt, will apply the SLP2 filters. If the software determines that the PER interrupt occurred within the range that is to be ignored, it will not take the action of TRACE indicated on SLP1. It is important to realize that even though the SLIP is taking action only on the first and last instructions of the range, every instruction in the range is being monitored by PER and when executed will trigger a PER interrupt to drive SLIP software. Therefore, coding A=IGNORE is a way to limit the volume of data produced by the SLIP trap to a subset of the targeted range, but it does not reduce the number of PER interrupts that occur and their potential for performance impact.
Specifying MODE=HOME indicates that the SLIP trap will only match when executing in the home address space. When MODE=HOME is specified, additional SLIP processing is required to monitor for the correct environment. When MODE=HOME is paired with the JOBNAME or ASID parameter, this monitoring is limited to processing associated with the specified address spaces. However, if MODE=HOME is specified without JOBNAME nor ASID, the additional monitoring required will affect processing in every address space on the system and could significantly impact system performance. Note that PRCNTLIM offers protection in this case, provided that PER interrupts are occurring.
There are times when coding JOBNAME or ASID along with MODE=HOME on a PVTMOD or PVTEP SLIP would make it too restrictive to trap the desired environment. Consider the case where the PER trap is intended to monitor a cross-memory environment where the module is loaded into private storage of an address space and then executed by a job with cross-memory access. Specifying MODE=HOME would be incorrect as it would prevent the SLIP trap from matching in such an environment. However, omitting the MODE=HOME parameter means that SLIP may potentially take additional PER interrupts and require additional processing in order to determine whether the PER interrupt occurred within the range of the specified private load module within the correct address space.
In cases where specifying MODE=HOME is too restrictive, try to at least specify JOBNAME or ASID. Remember to use a conservative PRCNTLIM if you are concerned about potential performance impact from your SLIP trap.
