Collecting diagnostic information

Abstract

Circuitry for performance analysis of operations with a data processing apparatus includes sampling circuitry to select a subset of operations within the data processing apparatus as sample operations to be performance analyzed. The circuitry also includes performance analysis circuitry to collect sample records for each operation selected by the sampling circuitry as a sample operation. A reference interval storage circuitry is provided to store an indication of a reference interval to be used for sampling of operations. The performance analysis circuitry supports collection of sample records for a plurality of monitoring contexts, with each monitoring context specifying a context sampling interval as a multiple of the reference interval. The performance analysis circuitry filters the collected sample records based on the respective context sampling interval for each monitoring context to produce a series of filtered sample records for the respective monitoring context.

Description

Background Technology

[0001] This technology relates to the field of data processing. More specifically, this technology relates to the collection of diagnostic information.

[0002] The data processing device may include circuitry for collecting diagnostic information about the software executing on the device. This diagnostic information can be used to analyze software performance to identify potentially poor-performing parts of the software program and possible causes of any performance problems. Software engineers can use the diagnostic information to optimize their software to reduce execution time and allow for better utilization of the available resources within the data processing device. Summary of the Invention

[0003] In one example arrangement, circuitry is provided for performing performance analysis on operations within a data processing apparatus. The circuitry includes: a sampling circuit for selecting a subset of operations within the data processing apparatus as sampled operations to be analyzed; a performance analysis circuit for collecting sample records for each operation selected as a sampled operation by the sampling circuit, the sample records including diagnostic information related to the sampled operation obtained from the data processing circuit; and a reference interval storage circuit for storing indications of reference intervals to be used for sampling operations. The performance analysis circuitry supports collecting sample records for each of a plurality of monitoring contexts, each monitoring context specifying a context sampling interval as a multiple of the reference interval. The performance analysis circuitry is configured to filter the collected sample records for each monitoring context based on the corresponding context sampling interval to produce a series of filtered sample records for the corresponding monitoring context.

[0004] In another example arrangement, a method is provided that includes: selecting a subset of operations within a data processing apparatus as sampling operations for performance analysis; collecting sample records for each selected operation as a sampling operation, the sample records including diagnostic information related to the sampling operation obtained from data processing circuitry; storing an indication of a reference interval to be used for sampling the operations; wherein collecting sample records for each selected operation as a sampling operation includes: collecting sample records for each of a plurality of monitoring contexts, each monitoring context specifying a context sampling interval as a multiple of the reference interval; and filtering the collected sample records for each monitoring context based on the corresponding context sampling interval to produce a series of filtered sample records for the corresponding monitoring context.

[0005] In another example arrangement, a computer program is provided for controlling a host data processing device to provide an instruction execution environment. The computer program includes: sampling program logic for selecting a subset of operations performed by data processing program logic as sampling operations to be used for performance analysis; performance analysis program logic for collecting sample records for each operation selected as a sampling operation by the sampling circuitry, the sample records including diagnostic information related to the sampling operation obtained from the data processing program logic; and a reference interval data structure for storing an indication of a reference interval to be used for sampling the operations. The performance analysis program logic supports collecting sample records for each of a plurality of monitoring contexts, each monitoring context specifying a context sampling interval as a multiple of the reference interval. The performance analysis program logic is configured to filter the collected sample records based on the corresponding context sampling interval for each configured monitoring context to produce a series of filtered sample records for the corresponding monitoring context. Attached Figure Description

[0006] Further aspects, features, and advantages of this technology will become apparent from the following description, which is taken in conjunction with the accompanying drawings.

[0007] Figure 1 An example of a data processing device with performance analysis circuitry is illustrated schematically;

[0008] Figure 2 This is a flowchart illustrating the operation of the sampling circuit and performance analysis circuit based on the example;

[0009] Figure 3 This is a flowchart illustrating the operation of a sampling circuit and a performance analysis circuit according to another example;

[0010] Figure 4 This illustrates the use of multiple context sampling intervals based on the example;

[0011] Figure 5 Another example of a data processing device with performance analysis circuitry is illustrated schematically;

[0012] Figure 6 Another example of a data processing device with performance analysis circuitry is illustrated schematically; and

[0013] Figure 7 A simulation example is illustrated schematically. Detailed Implementation

[0014] One type of diagnostic information collection that can be performed is statistical performance analysis. Statistical performance analysis, for example, involves selecting a subset of instructions for micro-operations processed by a data processing device based on rule-based intervals. During the processing of the selected operations by the data processing device, information about the behavior of the selected operations is collected to form a sample record that can be output for analysis. The information included in the sample record can directly indicate events that occurred during sample processing or the state of the data processing device while processing the sample. For example, the sample record can indicate whether an event, such as a cache miss in a given cache level or a branch misprediction for a given branch, has occurred. The sample record can also, or alternatively, indicate the latency of measuring certain events during the processing of the sampled operation or the cycle count of the latency of a memory access request at each cache level in a memory system. In cases where such memory access requests are processed by main memory, the diagnostic information can include indications of the dynamic random access memory (DRAM) bank serving the request. By using statistical performance analysis, only a subset of all operations processed by the data processing device is selected for performance analysis. Therefore, more detailed information about the processing of the sampled operations can be collected compared to the information about the processing of the sampled operations that would be collected using diagnostic techniques that aim to collect information related to all instructions processed by the data processing device or to count certain events that occur in the data processing device.

[0015] To support statistical performance analysis within the data processing device, the device may include a performance analysis circuit capable of collecting diagnostic information related to a specific sampling operation from numerous potential components within the data processing device and aggregating this information into a sample record. To avoid erroneous association of diagnostic information collected for one sampling operation with that of another, the performance analysis circuit may support collecting diagnostic information for only a single, ongoing sampling operation at a time.

[0016] The complexity involved in collecting this diagnostic information from various parts of the data processing device means that the performance analysis circuit is relatively expensive to implement; however, the insights provided by the execution of the software on the data processing device can still be valuable enough to justify including the circuit.

[0017] One approach to implementing statistical performance analysis is to provide a single instance of the performance analysis circuitry and a corresponding sampling circuitry that selects the operations to be sampled and identifies them for sampling. However, since the sampling circuitry / performance analysis circuitry is software-configurable, this approach can only provide a single monitoring context that can be configured to perform the statistical performance analysis. In other words, this approach allows only one software agent at a time to configure the statistical performance analysis with a single set of configuration information.

[0018] However, in some cases, it may be desirable to support multiple monitoring contexts to allow multiple software agents to utilize statistical performance analytics simultaneously and / or to allow a specific software agent to utilize multiple monitoring contexts with different configurations. For example, in a data processing device executing processes associated with a hypervisor that manages one or more guest operating systems (each of which executes an application), it may be desirable to support statistical performance analytics at the hypervisor level (to monitor the hypervisor's operation) and at the operating system and / or application level (to monitor the operating system / application). If a single monitoring context is supported and the hypervisor uses that single monitoring context, the operating system or application will not benefit from statistical performance analytics.

[0019] While data processing devices can be configured with multiple instances of performance analysis circuitry to support such multiple monitoring contexts, each capable of collecting diagnostic information for different sets of sample records, such approaches quickly become expensive in terms of the circuitry required to implement the performance analysis and the on-chip area needed to house such circuitry.

[0020] As described herein, a technique is provided that allows multiple monitoring contexts to be configured simultaneously (and thus for collecting diagnostic information for multiple different software agents). The circuitry implementing this form of statistical performance analysis restricts the allowed sampling interval to a multiple of a defined baseline interval. That is, instead of allowing the monitoring context to freely choose the sampling interval for its specific context, a baseline interval is defined, and the monitoring context specifies its context sampling interval as a multiple of the baseline interval.

[0021] Alternatively, if a monitoring context is allowed to freely choose the context sampling interval for a specific monitoring context, conflicts may occur between monitoring contexts if multiple monitoring contexts simultaneously select different ongoing sampling operations for sampling. This could lead to contamination of diagnostic information collected for sampling operations, where information collected for one operation is incorrectly associated with different operations.

[0022] Therefore, by allowing monitoring contexts to configure the sampling interval to a multiple of the reference interval, each monitoring context is provided with the ability to independently specify the rate at which it decides to sample the operation, while mitigating conflicts between competing monitoring contexts that utilize the same performance analysis circuitry.

[0023] Once sample records have been collected based on the baseline interval, the performance analysis circuitry can filter the collected sample records based on the context sampling interval for each monitoring context to produce a series of filtered sample records for each monitoring context.

[0024] Based on the technology described herein, circuitry for performing performance analysis on operations within a data processing apparatus is thus provided. The circuitry includes: a sampling circuit for selecting a subset of operations within the data processing apparatus as sampled operations to be subjected to performance analysis; and a performance analysis circuit for collecting sample records for the sampled operations. The sampling circuitry may, for example, select the operation to be sampled based on a reference interval completion count. In this way, the sampling circuitry may be configured to select the next sampled operation in response to a sampling interval completion count (elapse) counted by an interval counter (which may count up or down as an operation is observed). The performance analysis circuitry collects diagnostic information from various components of the data processing apparatus, which may report information related to the sampled operations to the performance analysis circuitry.

[0025] A reference interval storage circuit (which may take the form of a register) is provided to store an indication of the reference interval to be used for sampling the operation. In some examples, the reference interval may be fixed; however, in other examples, the reference interval may be modifiable by software to support different sampling intervals (those that are multiples of the reference interval).

[0026] The performance analysis circuitry then supports multiple monitoring contexts, each independently configurable with its own context sampling interval, which is specified as a multiple of the baseline interval. The performance analysis circuitry then collects sample records for all configured monitoring contexts and filters these records at least based on the specified context sampling interval for each monitoring context to generate sample records for various monitoring contexts. The sample records can then be written to a buffer in memory and / or to a port accessible from outside the chip.

[0027] In addition to counting and marking operations to be sampled, in some examples, the sampling circuitry also marks the sampling operations to indicate which monitoring contexts (if any) are associated with the sampling operation. Therefore, when an operation is processed (e.g., as an instruction progresses down the pipeline of a data processing circuit), the operation may carry an indication of a monitoring context for which the sampling operation can be included in a set of sample records. In such examples, the sampling circuitry may maintain a separate counter for each monitoring context to identify when a sampling operation is marked as associated with the corresponding monitoring context.

[0028] As an illustrative example, if the baseline interval is set to sample once every 100 instructions, the first monitoring context is sampled at a multiple of 2 (i.e., every 200 instructions) and the second monitoring context is sampled at a multiple of 5 (i.e., every 500 instructions), then every 200th instruction (subjected to the perturbation discussed below) will be marked as associated with the first monitoring context, and every 500th instruction will be marked as associated with the second monitoring context. Therefore, every 1000th instruction will be marked as associated with both the first and second monitoring contexts.

[0029] By using this tagging operation, performance analysis circuitry can filter the collected sample records based on the tags in order to determine which sample records should be reported for each monitoring context.

[0030] While the sampling circuitry can indicate the operation to be sampled based on a counting process corresponding to a reference interval, this approach can lead to situations where, for some monitoring contexts, operations are marked as sampling operations but are not actually being monitored by any monitoring context. Continuing with the illustrative example above, although the 100th, 300th, 700th, and 900th instructions can be selected based on the counting process of the reference interval, no monitoring context is configured to collect diagnostic information for such instructions. Therefore, in some examples, the sampling circuitry is configured to suppress the selection of operations that are not associated with any monitoring context. That is, for operations that would otherwise be selected for sampling based solely on the reference interval but for which no monitoring context will report sample records, the sampling circuitry can suppress their selection as sampling operations. This method prevents the performance analysis circuitry from unnecessarily collecting operation-related diagnostic information.

[0031] To support marking an operation as associated with one or more monitoring contexts, the sampling circuitry can maintain multiple context counters, each associated with a corresponding monitoring context. Then, when the context sampling interval for a given monitoring context has finished counting (as determined using context counters), the sampling circuitry can mark the next sampling operation (as determined using a reference interval counter) as associated with the given monitoring context.

[0032] While sampling circuitry can label operations based on the monitoring context associated with the operation, as discussed above, in some examples, sampling circuitry is configured to label operations as sampling operations based on a reference interval, without indicating the monitoring context associated with the operation. This reduces the amount of information that needs to be transmitted with the operation as it is processed by the data processing device (e.g., as instructions / micro-operations progress along the pipeline).

[0033] To filter the collected sample records, the performance analysis circuit can then count the observed sample records and select only a subset based on a corresponding multiple. Using this method, the context sampling counter can be implemented in the performance analysis circuit instead of the sampling circuit described above.

[0034] The context sampling interval for each of the multiple monitoring contexts can be independently programmable, for example, by allowing software to update registers that store the corresponding multiples used to define the context sampling interval, thereby enabling different software processes to define sampling rates suitable for the performance analysis they wish to perform.

[0035] To extract the collected diagnostic information, the circuitry may include multiple performance analysis buffers, and the performance analysis circuitry may be arranged to write sample records for each monitoring context to the corresponding performance analysis buffer. In some examples, the buffer can then be read from a trace output port, which allows external hardware to read the collected diagnostic information. However, in some examples, the collected diagnostic information for each monitoring context is written to a corresponding buffer in memory for access by the associated software process.

[0036] The sampling circuitry supports random perturbation of the sampling interval, allowing the performance analysis circuitry to adjust the interval using random or pseudo-random values ​​to set the sampling interval counted by the interval counter within a given time period if random perturbation is enabled. For example, the sampling interval can be user-configurable (by setting control data in a register) to specify the nominal number of instructions or micro-operations to be counted between two consecutive sampling operations, but this nominal value can be adjusted using random / pseudo-random values ​​to change the exact interval within one counting cycle compared to the next. This reduces the risk that the sampling circuitry might repeatedly select the same operation within a program loop in multiple iterations through the loop, potentially skewing the performance analysis results.

[0037] Because monitoring contexts can be configured independently, there may be situations where no monitoring context is enabled / configured at a given point. To prevent the performance analysis circuitry from collecting diagnostic information in such cases, the sampling circuitry can be configured to completely suppress the collection of sample records when all monitoring contexts are disabled. This can be achieved, for example, by stopping one or more counters at the sampling circuitry or otherwise by preventing the sampling circuitry from indicating any operation for sampling.

[0038] Statistical performance analysis can be implemented within a variety of possible forms of data processing devices and / or monitor a range of different operations and components within such devices. For example, a data processing device may include processing circuitry, such as the processing circuitry of a central processing unit (CPU) or a graphics processing unit (GPU). In such cases, the sampling operation may be instructions executed by the processing circuitry and / or micro-operations decoded from such instructions. In some examples, the data processing device includes a memory system, and circuitry may be arranged to monitor bus transactions (e.g., memory access requests) occurring within the memory system. The data processing device may also include devices connected via a transmission network (such as an interconnect), wherein the monitored operation is a bus transaction.

[0039] In cases where data processing circuitry is capable of operating at different privilege levels (which may also be referred to as exception levels), the circuitry may be provided with mechanisms to prevent processes operating at different privilege levels from accessing data associated with other privilege levels that are not permitted to be accessed.

[0040] Traditionally, processes executing at lower privilege levels should be prevented from accessing data at higher privilege levels, while processes at higher privilege levels should be allowed to access data associated with lower privilege levels. Therefore, performance analysis circuitry can be configured to prevent the collection of sample records associated with processes executing at higher privilege levels for a given privilege level monitoring context. Thus, if a monitoring context for a given privilege level is enabled and the data processing device begins operating at a higher privilege level, the performance analysis circuitry can prevent the collection of sample records for that given monitoring context until execution returns to the given privilege level (or a lower privilege level). This maintains security by preventing processes at a specific privilege level from obtaining information about processes at higher privilege levels.

[0041] However, in some examples, the data processing device may also restrict access to data associated with processes operating at lower privilege levels from processes at higher privilege levels (e.g., preventing the hypervisor from accessing data associated with the guest operating system). Therefore, performance analysis circuitry may also be operable to prevent higher privilege levels from collecting diagnostic information about processes operating at lower privilege levels.

[0042] The circuitry can also support the use of selection criteria to further filter sample records reported for specific monitoring contexts. One or more selection criteria can be specified as part of the monitoring context configuration. For example, selection criteria can be used to cause the performance analysis circuitry to report only diagnostic information related to certain types of operations (e.g., branch instructions or load / store operations). Therefore, the amount of data collected can be reduced by filtering out information related to unwanted operations. The use of selection criteria can be combined with the provision of multiple monitoring contexts (even within a single process) to enable the collection of diagnostic information at different frequencies for different types of operations. In other words, by using different monitoring contexts that define different context sampling intervals and different selection criteria, the process can utilize several monitoring contexts to collect the desired amount of information.

[0043] In some examples, statistical performance analysis can be combined with one or more other diagnostic techniques. One such diagnostic technique is performance monitoring, which provides multiple event counters, each maintaining a corresponding event count value based on monitoring of events during software processing by the data processing unit. Each counter can be individually configured to count certain types of events, such as cache misses, branch mispredictions, pipeline stalls, or the number of clock cycles elapsed.

[0044] In conjunction with the techniques for statistical performance analysis described herein, the data processing apparatus may be equipped with performance monitoring circuitry that supports counting of aggregate events to complete the counting of baseline intervals and / or context sampling intervals associated with any monitoring context. In this way, performance monitoring can be used in conjunction with statistical performance analysis, where these aggregate events are used to correlate data collected according to each technique.

[0045] A specific example will now be described with reference to the accompanying drawings.

[0046] Figure 1 An example of a data processing device 2 including a processing circuit 4 for performing data processing is schematically illustrated. The processing circuit 4 includes a processing pipeline with multiple pipeline stages, which in this example include an extraction stage 6, a decoding stage 8, a publishing stage 10, an execution stage 12, and a write-back stage 14. It should be understood that this is only one example of a possible pipeline configuration, and other examples may have different numbers of stages and may include other types of pipeline stages.

[0047] Fetch stage 6 fetches instructions from level 1 instruction cache 16 for pipeline execution. Branch predictor 18 provides predictions of the results of branch instructions, which can be used by fetch stage 6 to determine which instructions to fetch beyond the branch. The instructions fetched by fetch stage 6 are decoded by decode stage 8 to generate control signals for controlling subsequent pipeline stages to execute the operations represented by the instructions. Decoding stage 8 maps the instructions to micro-operations, which represent operations to be executed at the granularity of micro-operations executable by execution stage 12.

[0048] In some pipeline implementations, there is always a one-to-one mapping between instructions fetched from memory and micro-operations, as will be seen later. Therefore, a micro-operation can be simply viewed as equal to or representing the originally fetched instruction itself (although it is still possible to represent a micro-operation differently depending on the corresponding instruction—for example, by labeling the micro-operation with additional information, such as the “sampled operation” label described below). Such pipeline implementations can be viewed as directly executing the instruction (without needing to decode the instruction into a micro-operation because there is no change in the mapping) or as executing the micro-operation decoded from the instruction through a one-to-one mapping. Both views can be considered equivalent descriptions of the same pipeline.

[0049] In other examples, for at least some instructions, the pipeline may support one-to-many or many-to-one mappings from instructions to micro-operations. Some instructions may still correspond to a single micro-operation. Other instructions may be broken down into multiple micro-operations by the decoding stage 8. The decoding stage 8 may also support the fusion of two or more program instructions fetched from cache 16 to form a single combined micro-operation supported by execution stage 12. Therefore, the micro-operation seen by execution stage 12 may differ from the architectural definition of the instructions defined in the instruction set architecture supported by data processing device 2.

[0050] In the following description, the term "micro-operation" refers to the form of an instruction as seen during the execution phase. This may simply be the original instruction of some pipeline, or it may be a modified form of an instruction or a micro-operation obtained by breaking down an instruction into multiple micro-operations or by merging multiple instructions into a combined micro-operation.

[0051] The release phase 10 queues the micro-operations generated by the decoder 8 while waiting for operands to become available, and releases the micro-operation for execution when its operands become available (or when it is known that the operands will become available at the relevant cycle time of the execution phase requiring operands). The execution phase 12 includes multiple execution units 22-28 for executing different types of micro-operations. Processing operations are performed by execution units 22-28 based on operands read from register 20. For example, the execution units of execution phase 12 may include an arithmetic / logic unit (ALU) 22 for performing arithmetic or logical operations, a floating-point unit 24 for performing operations involving numbers represented as floating-point values, a branch unit 26 for determining whether a branch instruction should be taken or not and for adjusting the program flow to perform non-sequential changes in the program flow when a branch is taken, and a load / store unit 28 for handling load operations (for loading data from the memory system into register 20) and store operations (for storing data from register 20 into the memory system). It should be understood that... Figure 1 The specific set of execution units 22-28 shown in execution phase 12 of the example is only one possible arrangement, and other examples may have execution units of different types or multiple execution units of the same type (e.g., multiple ALUs 22). Write-back phase 14 writes the results of the executed instructions back to register 20.

[0052] Processing pipeline 4 can be a sequential processing pipeline, restricted to executing micro-operations in an order corresponding to the program order, where instructions are qualified by a programmer or compiler and where instructions are fetched by fetch stage 6. Alternatively, processing pipeline 4 can support non-sequential processing, where publish stage 10 allows publish operations to be executed in an order that may differ from the program order. For example, while a micro-operation stalls and waits for its operands to become available, a later micro-operation associated with a later instruction in the program order can be executed before the stalled instruction. If the pipeline supports non-sequential processing, additional pipeline stages, such as a renaming stage, can be provided to remap the architecture register specifiers specified by the decoded program instructions to physical register specifiers of specific hardware registers in identifier register set 20.

[0053] In this example, the memory system includes a Level 1 instruction cache 16, a Level 1 data cache 30, a shared Level 2 cache 32 for both data and instructions, and main memory 34, which may include multiple memory storage units, peripheral devices, and other devices accessible via load / store instructions executed via pipeline 4. It should be understood that... Figure 1The specific cache level shown is only one example, and other examples may have different numbers of cache levels, or may provide different arrangements of instruction cache relative to data cache (e.g., a Level 2 cache 32 may be divided into separate Level 2 instruction and data caches). A memory management unit 36 ​​is provided for controlling address translation between virtual addresses (generated based on operands of instructions processed by processing pipeline 4) and physical addresses identifying locations to be accessed in the memory system. MMU 36 may include at least one translation back buffer (TLB) 38 for caching information that defines the address translation mapping based on page table data obtained from memory system 34, and may also provide access control over certain regions of the address space for access by a specific process executing on pipeline 4. Although for the sake of brevity, MMU 36 is... Figure 1 The MMU 36 is shown as being connected to the load / store unit 28 for data access, but it can also be used to translate addresses when fetching instructions for execution and to check the access permissions of the instruction fetch address issued by the fetch unit 6.

[0054] Figure 1 The processor architecture described is just one example, and other examples may have... Figure 1 Other components not explicitly indicated in the document.

[0055] To aid software development, processor 2 is provided with hardware resources that allow for the collection of performance analysis information regarding the behavior of instructions processed by processing pipeline 4. Software developers can use this performance analysis information to perform code optimization, aiming to modify their code for more efficient operation. Sampling circuitry 50 is provided to select certain instructions or micro-operations as sampling operations to be analyzed by performance analysis circuitry 52. ​​Sampling circuitry 50 can select sampling operations at different stages of the pipeline. For example, sampling circuitry 50 can select certain fetch instructions as sampling operations and mark those fetch instructions in fetch stage 6 to indicate that performance analysis circuitry 52 should collect information about the behavior of the sampling operations as the instructions progress down pipeline 4. Alternatively, the marking of instructions for sampling operations by the sampling circuitry can be performed in decoding stage 8 or a later stage. Sampling operations can also be selected at the granularity of individual micro-operations, rather than at the granularity of architectural program instructions fetched from memory.

[0056] The advantage of selecting only a subset of operations as sampled operations is that it significantly reduces the overhead of tracking information used for performance analysis. For example, the sampling interval can be set long enough that only a single operation in flight within pipeline 4 is selected as a sampled operation at a time, so that the performance analysis circuit 52 only needs to be provided with sufficient hardware resources to track the behavior of a single sampled operation at a time. This avoids the overhead of having to index a memory structure that can store information for multiple operations based on the operation identifier associated with a particular sampled operation, in order to select which entry in the memory structure should be updated based on the information for that particular sampled operation.

[0057] The performance analysis circuit 52 includes a monitoring circuit 70 for collecting information about the behavior of the sampled operation selected by the sampling circuit 50. Although the monitoring circuit 70 is shown as a single box within the performance analysis circuit 52, in practice, the monitoring circuit may include multiple elements distributed around the processor to collect information from different components of the processor. For example, the monitoring circuit 70 may include event detection circuitry to detect the occurrence of various types of events related to the sampled operation. The type of event detected may depend on the type of sampled operation. For example, for a branch operation selected as a sampled operation, the event may track whether a branch misprediction occurred or whether the branch predictor 18 correctly predicted the branch. For a load / store operation, the event may include, for example, whether the load / store operation is missing in a specific level of cache 30, 32, whether the address translation lookup table for the load / store instruction is missing in TLB 38 or in a specific level of TLB, or whether an address fault occurred for the load / store instruction. Other types of events that may be monitored may be a missing instruction fetch in instruction cache 16, a fault such as an undefined instruction exception, or whether certain instructions are delayed due to contention for resources. The monitoring circuit 70 can also capture information about specific instructions, such as the instruction address of a sampling operation, the target address of a load / store operation, or the branch target address of a branch operation, as well as architectural state entries from register 20 captured at the point where the sampling operation reaches a specific processing stage (e.g., a context identifier identifying the processing context in which the sampling operation is processed). For example, the monitoring circuit 70 may also have a cycle counter that counts the number of processing cycles taken to complete certain operations, such as measuring the latency of address translation or cache lookup tables, or the number of cycles that allow an operation to progress between a first processing point and a second processing point. Therefore, it should be understood that the monitoring circuit 70 can collect a variety of information.

[0058] The captured monitoring information can be recorded in a sample record, which is stored in the sample record storage circuit 72 (e.g., a register or buffer) of the performance analysis circuit 52. Within the sample record captured for a given sampling operation, the record can specify the type of operation associated with the sampling operation (e.g., whether it is a branch, load / store operation, or ALU operation, etc.) and also provides various information directly attributable to the sampling operation. The capture of the sample record in the sample record storage device 72 is performed in hardware in the context of processing performed on pipeline 4, so no specific software instructions need to be executed to collect the information within the sample record.

[0059] Performance analysis circuit 52 and sampling circuit 50 are arranged to support concurrent collection of performance analysis data for multiple software agents. Figure 1 In the example shown, the device supports two monitoring contexts, enabling the collection of performance analysis data for two software agents simultaneously; however, it should be understood that more monitoring contexts can be supported by providing a configuration register 78, filtering circuitry 86, standard application circuitry 74 (if used), and sample record writing circuitry 79 for each additional monitoring context.

[0060] This method supports the use of multiple monitoring contexts without requiring additional monitoring circuitry to collect diagnostic information for each monitoring context, and without requiring circuitry to distinguish diagnostic information collected simultaneously for multiple ongoing sampling operations. To this end, a reference interval storage device 80 is provided to store reference intervals, allowing the operations used for sampling to be specified in integer multiples of the reference interval. The reference interval itself can be fixed in the hardware implementation or can be modified by the user via software.

[0061] The performance analysis circuit also provides monitoring contexts for each monitoring context ( Figure 1Two of the monitoring contexts shown are provided with configuration registers 78 to allow software to specify certain configuration details for the monitoring context. The configuration register 78 for each monitoring context includes an enable register 84 to indicate whether the associated monitoring context is enabled. A context multiple register 82 is also provided, where the context sampling interval for the monitoring context can be specified as a multiple of a reference interval. For example, if the reference interval (as indicated by the reference interval storage circuitry 80) is 500, the context multiple register 82 for one of the monitoring contexts can be specified as a multiple of 4 to indicate that sampling will be performed based on every 2000th operation. It should be understood that the configuration register 78 can store other items of configuration information, such as configuration information for controlling the filtering standard application performed by the standard application circuitry 74 (discussed below). The context sampling interval can also be specified in other ways (e.g., by specifying the interval directly instead of as a multiple); however, typically, the context sampling interval is limited to an integer multiple of the reference interval.

[0062] The sampling circuit 50 has an interval counter 54 for counting instructions or micro-operations to determine when the next sampling operation should be selected. In some examples, the interval counter 54 triggers the counter to complete counting based on a reference interval, such as that held in a reference interval storage circuit 80, and marks the operation used for sampling according to that frequency. The sampling circuit 50 may also be provided with corresponding counters for monitoring the context, such as... Figure 1 The A counter 92 and B counter 93 shown are corresponding counters that can be used to count when a context sampling interval has been counted. For example, a counter can increment / decrement its count in response to a reference interval being counted by counter 54, and trigger its count completion when a specified multiple for the corresponding monitoring context has been reached. Alternatively, context counters 92 and 93 can count for each operation and trigger the counter to complete counting when a context sampling interval (as defined based on a relevant multiple and a reference interval) has been reached.

[0063] Sampling circuit 50 may use counts for different monitoring contexts to suppress the selection of sample records not monitored by any monitoring context. Additionally or alternatively, sampling circuit may use indications of the monitoring context associated with the sampling operation to mark the sampling operation, allowing filtering circuit 86 of performance analysis circuit 52 to more easily select sample records associated with each monitoring context.

[0064] The sampling circuit 50 can also support a random perturbation function, wherein the sampling interval is perturbed by random or pseudo-random values ​​generated by a random number generator or pseudo-random number generator 56. Although Figure 1A pseudo-random number generator 56 is shown within sampling circuit 50, but in other examples, the sampling circuit may reuse (pseudo)random numbers generated by a (pseudo)random number generator set up elsewhere in the processing system, also for purposes other than instruction or micro-operation sampling. For example, (pseudo)random number generator 56 may generate random values ​​within a specific range, which are added to (or subtracted from) a specified reference sampling interval to generate a sampling interval that will be counted by interval counter 54 for the next operating cycle. Enabling random perturbation can be useful because it reduces the risk that the same instruction or micro-operation may be selected as the sampling operation on multiple iterations of the processing instruction cycle. In some implementations, it is optional to enable or disable random perturbation, where user-configurable control parameters enable or disable random perturbation.

[0065] Regardless of how sampling circuit 50 determines the completion of the sampling operation count, the operation selected for sampling is marked as a sampling operation. For example, a flag bit associated with an instruction or micro-operation can be set, and this flag bit can accompany the instruction or micro-operation as it progresses down pipeline 4. Similarly, a monitoring context bit can be set for each supported monitoring context to indicate whether the sampling operation is associated with each monitoring context.

[0066] Returning to the performance analysis circuit 52, a filtering circuit 86 is provided to filter the collected sample records, thereby extracting only those relevant to the monitoring context. For example, if the multiplier for a specific monitoring context is set to 10, the filtering circuit 86 can filter out all sample records except the 10th sample record collected by the performance analysis circuit 52. To support this filtering, the filtering circuit 86 may be equipped with counters 87 and 88 to count the collected sample records and discard those whose counters have not yet finished counting. However, if the sampling circuit 50 tags operations based on the monitoring context relevant to the operation, the filtering circuit 86 does not need to be equipped with such counters 87 and 88, and the performance analysis circuit 52 can instead use tags to perform the filtering. Regardless of how the filtering is performed, the filtering circuit 86 enables the use of different sampling intervals for different monitoring contexts by removing sample records irrelevant to a specific monitoring context.

[0067] A standard application circuit 74 is provided to allow the performance analysis circuit 52 to apply additional criteria when selecting whether sample records captured for a specific sampling operation are available for diagnostic analysis. Figure 1In the illustrated implementation, sample records can be made available for diagnostic analysis by writing them to corresponding performance analysis buffer structures 90, 91 stored in memory system 34. The address ranges allocated for use as performance analysis buffers 90, 91 can be determined based on buffer address identification information stored in configuration register 78 of performance analysis circuit 52, which can be set by the user under software control. Configuration register 78 may also include configuration information specifying what type of information should be included in the sample record for a particular type of sampling operation, and this configuration information is used to set the standards used by standard application circuit 74. Writing sample records to performance analysis buffers 90, 91 in memory can be performed without processing on interrupt pipeline 4, so that no specific software instructions are required to store sample records in memory system. Therefore, a specific number of sample records can be output to performance analysis buffers 90 and 91 without any interruption, until a sufficient number of sample records have been generated and written, at which point the performance analysis buffers risk overflowing these sample records. At this point, a performance monitoring interrupt can be triggered to interrupt the process and allow the exception handler to then take action to ensure that the sample records previously stored in performance analysis buffers 90 and 91 remain available for diagnostic analysis (e.g., by updating the address parameters in configuration register 78 to allow subsequent sample records to be stored in performance analysis buffers in different regions of the address space, or by reading sample records from the performance analysis buffers and storing them elsewhere or outputting them for external analysis). Although Figure 1 An example is shown of making sample records available for diagnostic analysis by writing them to memory. However, an alternative would be to output these sample records to trace buffers 94, 95 (a dedicated hardware structure separate from memory system 34 for storing diagnostic information on-chip), and / or to output the captured sample records via trace output port 75 (directly or via trace buffers 94, 95), which is an integrated circuit pin set through which sample records can be output to an external off-chip trace analyzer or storage device. Some systems may support this trace output functionality, rather than the ability to write sample records to memory, while others may support both methods and can use the configuration information in register 78 to select which method to use.

[0068] Figure 2This is a flowchart illustrating the operation of the sampling circuit and performance analysis circuit according to the example. The sampling circuit 50 monitors the operation processed by the data processing device, and in response to detecting at step 202 that a counter corresponding to the reference interval (subject to any additional disturbance) has completed counting, the sampling circuit marks the operation to be sampled at step 204. This marking can be accomplished, for example, by setting a flag bit within the operation to indicate that the operation is to be sampled.

[0069] In the case where the operation is marked in this way, the performance analysis circuit 52 then, at step 206, collects diagnostic information about the processing of the operation from various components in the data processing device while the operation is being processed.

[0070] For each enabled monitoring context, the performance analysis circuit 52 maintains a counter to allow the performance analysis circuit 52 to determine at steps 208, 214 whether the context sampling interval for that monitoring context has been counted. Figure 2 Two such steps are shown, but it should be understood that this determination can be repeated for each monitoring context when more than two monitoring contexts are supported. If the context sampling interval for a particular monitoring context has not yet been counted, no sampling record is recorded, as shown at step 220. Since sampling records can be collected at a more frequent frequency than the context sampling interval, which is controlled by the baseline interval, not all sample records typically collected by the performance analysis circuit 52 will be applicable to each monitoring context.

[0071] In some examples, additional filtering steps 210, 216 may be performed for each monitoring context to determine whether certain additional selection criteria are met. These selection criteria may, for example, be used to restrict sample records to only certain types of operations. If the criteria are not met, no sample record is written for the monitoring context, as shown in step 220, while if any imposed criteria are met, a sample record is written at steps 212, 218.

[0072] Figure 2 An example is shown in which the sampling circuit completes a count based on a reference interval to identify the operation used for sampling, but does not track which monitoring context(s) the operation will be associated with. Figure 3 This is a flowchart illustrating the operation of a sampling circuit and a performance analysis circuit according to another example, wherein the sampling circuit 50 tracks the context sampling interval and marks the operation based on the monitoring context associated with the operation.

[0073] In this example, sampling circuit 50 again tracks the reference interval. However, in response to the reference interval completing its count, as determined at step 302, sampling circuit 50 determines at steps 304 and 306 whether the context sampling interval for each monitoring context has also been counted. If the context sampling interval for a particular monitoring context has not yet been counted, no action is required, and the sampling circuit can continue its operation. However, if the context sampling interval for a given monitoring context has been counted, sampling circuit 50 marks the operation at steps 308 and 310 as being for sampling by the relevant monitoring context. Therefore, in this example, if the operation is not relevant to any monitoring context, it is not marked as being for sampling at all.

[0074] The performance analysis circuit collects diagnostic information about the identified operation to generate sample records for that operation. In this example, the filtering performed by the performance analysis circuit 52 can be done based on instructions provided by the sampling circuit 50. At steps 314 and 320, it is determined whether the sample record is relevant to each monitoring context, and if the sample record is not relevant, no sample record is written for that monitoring context (as shown in step 326). Then, at steps 316, 318, 322, and 324, the filtering can be performed for each monitoring context as relative to... Figure 2 The similar monitoring and logging steps discussed.

[0075] Figure 4 The use of multiple context sampling intervals, defined as multiples of the reference interval, is conceptually illustrated. Figure 4 A timeline is shown, where each short line represents an operation processed by the data processing unit. Letters are displayed above some of the short lines to indicate the monitoring context in which performance analysis will be performed on that operation.

[0076] like Figure 4 As shown, the baseline sampling interval n is 10, and the context sampling interval for each of the two monitoring contexts is represented as a multiple of this baseline sampling interval. Specifically, context sampling interval A samples once every 20 operations (represented as 2n), and context sampling interval B samples once every 30 operations (represented as 3n). The initial operation is counted as operation 0, and operation 0 will be performance analyzed by both monitoring context A and monitoring context B. Then, operation 20 will be sampled only by monitoring context A, operation 30 will be sampled only by monitoring context B, operation 40 will be sampled only by monitoring context A, and then operation 60 will be sampled by both monitoring context A and monitoring context B. In this way, different monitoring contexts can be configured with different sampling intervals, while allowing multiple monitoring contexts to utilize the same performance analysis circuitry.

[0077] Figure 5 Another example of a data processing apparatus 200 with performance analysis circuitry 52 and sampling circuitry 50 is schematically illustrated. Here, the data processing apparatus has two central processing units (CPUs) 104 and an input / output unit 106 for controlling the input or output of data from / to peripheral devices. It should be understood that many other types of devices may also be provided, such as a graphics processing unit (GPU), a display controller for controlling the display of data on a monitor, a direct memory access controller for controlling access to memory, etc. At least some of the devices may have an internal data or instruction cache 108 for caching instructions or data local to the device. Other devices (such as the input / output interface 106) may be uncached devices. The consistency between data in the corresponding cache and data accessed by the corresponding device may be managed by a consistency interconnect 100, which tracks requests for accessing data from a given address and controls snooping on data in the caches of other devices when consistency needs to be maintained. It should be understood that in other embodiments, such consistency operations may be managed in software, but the benefit of providing a hardware interconnect 100 for tracking such consistency is that the programmer of the software executed by the system does not need to consider consistency.

[0078] like Figure 5 As shown, some devices may include a memory management unit (MMU) 112, which may include at least one address translation cache for caching address translation data used to translate software-specified addresses into physical addresses referencing specific locations in memory 114. A system memory management unit (SMMU) 116 may also be provided, which is not provided within a given device but rather as an add-on between a particular device 106 and the coherence interconnect 100, to allow simpler devices not designed with a built-in MMU to use address translation functionality. In other examples, SMMU 116 may be considered part of interconnect 100.

[0079] Devices 104, 106, and memory 114 can communicate with each other via interconnect 100 through exchange bus transactions. Users may wish to monitor these bus transactions to extract diagnostic information from a subset of these transactions. Within the data processing apparatus 200, performance analysis circuitry 52 and sampling circuitry 50 are provided to implement the performance analysis techniques discussed above. Specifically, sampling circuitry 50 can flag selected bus transactions occurring within apparatus 200 for performance analysis by performance analysis circuitry 52. ​​As discussed above, sampling circuitry 50 and performance analysis circuitry 52 can support multiple monitoring contexts to allow multiple software agents to configure performance analysis and / or allow software agents to configure multiple performance analysis instances.

[0080] Figure 6 Another example of a data processing device 2 with performance analysis circuitry 52 is schematically illustrated. In this case, Figure 6 Many of the components shown are similar to Figure 1 The components shown will not be repeated in their entirety, nor will a full discussion of their features and functionality be repeated. However, in this example, the performance analysis circuitry is arranged to monitor bus transactions between the processing circuitry 4 and the memory systems 16, 30, 32, and 34. That is, the sampling circuitry 50 is arranged to monitor transactions from the execution phase 12 of pipeline 4 (e.g., memory access requests) and / or transactions from the fetch phase 6 of pipeline 4 (such as instruction fetching), and to flag the sampled bus transactions for performance analysis by the performance analysis circuitry 52 according to the techniques described herein.

[0081] Figure 7Examples of emulator implementations that can be used are illustrated. While the previously described embodiments implement the invention in terms of means and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented using a computer program. Such computer programs are generally referred to as emulators, in part because they provide a software-based implementation of a hardware architecture. Types of emulator computer programs include simulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the emulator implementation can run on host hardware 730, which optionally runs a host operating system 720 supporting the emulator program implemented by emulator code 710. In some arrangements, multiple emulation layers may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors were required to provide emulator implementations that execute at a reasonable speed, but such approaches may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, the emulator implementation may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of the simulation is given in the following literature: “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0082] With respect to embodiments previously described with reference to specific hardware constructions or features, equivalent functionality may be provided in simulated embodiments by suitable software constructions or features. For example, specific circuitry may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or cache memory may be implemented as software data structures in simulated embodiments. Where one or more of the hardware elements referenced in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 730), some simulated embodiments may utilize the host hardware where appropriate.

[0083] The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems, and management programs), the same as the interface of the hardware architecture modeled by the simulator program 710. Therefore, the simulator program 710 can execute program instructions of the target code 700 from within the instruction execution environment, enabling the host hardware 730, which does not actually possess the hardware features of the circuits discussed above, to simulate these features. Thus, the features of the sampling circuit 50 and the performance analysis circuit 52 can be simulated by the corresponding program logic 712, 714. The simulator code 710 may also have code for managing the internal data structure 716 of the reference to simulate the reference interval storage circuit 80. Providing a simulation of the circuits described herein allows for the development of software for interacting with the sampling circuit and the performance analysis circuit before the hardware is actually available.

[0084] In this application, the phrase "configured as..." is used to mean that the elements of the device are configured to perform the defined operations. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operations, or a processor or other processing device may be programmed to perform the function. "Configured as" does not mean that the elements of the device need to be changed in any way to provide the defined operations.

[0085] While exemplary embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention as defined in the appended claims.

Claims

1. A circuit for performing performance analysis of operations within a data processing device, the circuit comprising: A sampling circuit, the sampling circuit being used to select a subset of operations within the data processing device as the sampling operations to be used for performance analysis; A performance analysis circuit is configured to collect sample records for each operation selected by the sampling circuit as a sampling operation, the sample records including diagnostic information related to the sampling operation obtained from a data processing circuit. and A reference interval storage circuit is used to store an indication of a reference interval to be used for sampling the operation; The performance analysis circuitry mentioned therein supports collecting sample records for each of multiple monitoring contexts, with each monitoring context specifying a context sampling interval as a multiple of the baseline interval; The performance analysis circuit is configured to filter the collected sample records for each monitoring context based on the corresponding context sampling interval, so as to generate a series of filtered sample records for the corresponding monitoring context.

2. The circuit according to any of the preceding claims, wherein the sampling circuit is configured to select the next sampling operation in response to the completion of a sampling interval counted by an interval counter.

3. The circuit according to claim 1 or claim 2, wherein: The sampling circuit is configured to identify the sampling operation to indicate any monitoring context associated with the sampling operation; and The performance analysis circuit is configured to filter the collected sample records for each configured monitoring context based on the identifiers performed by the sampling circuit.

4. The circuit of claim 3, wherein the sampling circuit is configured to suppress the selection of operations that are not associated with any monitoring context.

5. The circuit according to claim 3 or claim 4, wherein: The sampling circuit maintains multiple context counters, each context counter being associated with a corresponding monitoring context; and The sampling circuit completes counting in response to a context sampling interval for a given monitoring context, which is counted by an associated context counter, to mark the next sampling operation as associated with the given monitoring context.

6. The circuit according to claim 2, wherein: The sampling interval corresponds to the reference interval; and The performance analysis circuit is configured to filter the collected sample records based on a specified multiple for each monitoring context.

7. The circuit according to any of the preceding claims, wherein the context sampling intervals for the plurality of monitoring contexts are independently programmable.

8. The circuit according to any of the preceding claims, the circuit comprising a plurality of performance analysis buffers, wherein the performance analysis circuit is configured to write the sample records for each configured monitoring context to a corresponding performance analysis buffer.

9. The circuit according to any one of claims 2 to 8, wherein when random perturbation of the sampling interval is enabled, the sampling circuit is configured to apply random or pseudo-random perturbation to the sampling interval counted by the interval counter.

10. The circuit according to any of the preceding claims, wherein the sampling circuit is configured to suppress the collection of sample records when all monitoring contexts are disabled.

11. The circuit according to any of the preceding claims, wherein the data processing means includes processing circuitry for executing instructions, and the operation includes instructions and / or micro-operations decoded from the instructions.

12. The circuit according to any one of claims 1 to 10, wherein the data processing device includes a memory system, and the operation includes bus transactions.

13. The circuit according to any one of claims 1 to 10, wherein the data processing means comprises two or more devices interconnected via an interconnection, and the operation comprises bus transactions.

14. The circuit according to claim 11, wherein: The data processing device is capable of operating at multiple privilege levels, thereby by default, a process executing at a given privilege level can access data associated with a process executing at a lower privilege level, and is prevented from accessing data at a higher privilege level; and For monitoring contexts associated with a specific privilege level, the performance analysis circuitry is configured to prevent the collection of sample records associated with processes executing at privilege levels higher than the specific privilege level.

15. The circuit according to claim 14, wherein: The data processing device is operable to restrict access to data associated with a process at a given privilege level from processes at a higher privilege level; and The performance analysis circuit, in response to one or more higher privilege levels being blocked from accessing a process at the given privilege level, prevents the collection of sample records associated with the process at the given privilege level for the monitoring context of the one or more higher privilege levels.

16. The circuit according to any preceding claim, wherein the performance analysis circuit specifies one or more selection criteria in response to a configured monitoring context to suppress collected sample records that do not meet the one or more selection criteria for the monitoring context.

17. The circuit according to any of the preceding claims, further comprising: A performance monitoring circuit includes a plurality of event counters, each event counter being used to maintain a corresponding event count value based on monitoring of a specified event during the processing operation by the data processing device; The performance monitoring circuitry, in response to performance monitoring configuration information for a given event counter specifying an overall event for a specific monitoring context, updates the given event counter in response to the completion of the context sampling interval for the specific monitoring context.

18. An apparatus comprising the circuitry according to any of the preceding claims and the data processing apparatus.

19. A method comprising: Select a subset of operations within the data processing device as the sampling operations for performance analysis; For each operation selected as a sampling operation, a sample record is collected, the sample record including diagnostic information related to the sampling operation obtained from the data processing circuitry; Stores an indication of the reference interval to be used for sampling the operation; The collection of the sample record for each operation selected as a sampling operation includes: collecting sample records for each of a plurality of monitoring contexts, wherein each monitoring context specifies a context sampling interval as a multiple of the baseline interval; as well as For each monitoring context, the collected sample records are filtered based on the corresponding context sampling interval to generate a series of filtered sample records for the corresponding monitoring context.

20. A computer program for controlling a host data processing device to provide an instruction execution environment, the computer program comprising: Sampling procedure logic, which is used to select a subset of operations performed by the data processing procedure logic as sampling operations to be performed for performance analysis; Performance analysis program logic, which is used to collect sample records for each operation selected by the sampling circuit as a sampling operation, the sample records including diagnostic information related to the sampling operation obtained from the data processing program logic; and A reference interval data structure for storing an indication of a reference interval to be used for sampling the operation; The performance analysis program logic mentioned above supports collecting sample records for each of multiple monitoring contexts, with each monitoring context specifying the context sampling interval as a multiple of the baseline interval; The performance analysis program logic is configured to filter the collected sample records based on the corresponding context sampling interval for each configured monitoring context, so as to generate a series of filtered sample records for the corresponding monitoring context.

Images