Performance and memory access tracking

Abstract

A technique for performing memory operations is disclosed herein. This technique includes generating a plurality of performance log entries based on observed operations and generating a plurality of memory access log entries based on observed operations, each of which performance log entries is associated with one or more memory access log entries from the plurality of memory access log entries, each of which performance log entries is associated with an epoch, and each memory access log entry is associated with an epoch and a memory address range.

Description

Technical Field

[0001] (Cross - reference to Related Applications) This application claims priority to U.S. Patent Application No. 18 / 192,694, filed on March 30, 2023, entitled "PERFORMANCE AND MEMORY ACCESS TRACKING", which is hereby incorporated by reference in its entirety.

Background Art

[0002] Computation performance is partially dependent on memory performance. Therefore, improvement in computation performance can be achieved by optimizing memory access. Further, more specific insights into memory access performance can, at least theoretically, provide an increase in the ability to improve performance. However, attempting to obtain such specific insights can itself affect performance, which can distort measurements and lead to inaccurate measurement results. Improvements in performance profiling are continuously being made.

[0003] A more detailed understanding can be obtained from the following description, given as an example along with the accompanying drawings.

Brief Description of the Drawings

[0004] [Figure 1] It is a block diagram of an exemplary device that can implement one or more features of the present disclosure. [Figure 2] It is a diagram showing details of the device of FIG. 1 according to an example. [Figure 3] It is a diagram showing an exemplary operation of a logger. [Figure 4] It is a flowchart of a method for performing cache operations according to an example.

Detailed Description of the Invention

[0005] Techniques for performing profiling operations are disclosed herein. These techniques include generating a plurality of performance log entries based on observed operations and generating a plurality of memory access log entries based on observed operations, wherein each of the plurality of performance log entries is associated with one or more of the plurality of memory access log entries, each performance log entry is associated with an epoch, and each memory access log entry is associated with an epoch and a memory address range.

[0006] Figure 1 is a block diagram of an exemplary computing device 100 that can implement one or more features of the present disclosure. In various examples, the computing device 100 is, but is not limited to, any of the following: a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, a tablet computer, or any other computing device. The device 100 includes, but is not limited to, one or more processors 102, memory 104, one or more auxiliary devices 106, and storage devices 108. An interconnection 112, which may be a bus, a combination of buses, and / or any other communication component, links the one or more processors 102, memory 104, one or more auxiliary devices 106, and storage devices 108 in a communicative manner.

[0007] In various alternatives, one or more processors 102 include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, each of which may be a CPU, GPU, or neural processor. In various alternatives, at least a portion of the memory 104 is located on the same die as one or more of the one or more processors 102, such as on the same chip or within an interposer configuration, and / or at least a portion of the memory 104 is located independently of the one or more processors 102. The memory 104 includes volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM, cache).

[0008] The storage device 108 includes fixed or removable storage devices (e.g., hard disk drives, solid-state drives, optical discs, flash drives, etc.). One or more auxiliary devices 106 include, but are not limited to, one or more auxiliary processors 114 and / or one or more input / output ("IO") devices. The auxiliary processor 114 includes, but are not limited to, a processing unit capable of executing instructions such as a central processing unit, a graphics processing unit, a parallel processing unit capable of performing computational shader operations in single instruction multiple data formats, a multimedia accelerator such as a video encoding or decoding accelerator, or any other processor. Any auxiliary processor 114 can be implemented as a programmable processor that executes instructions, a fixed-function processor that processes data according to fixed hardware circuits, a combination thereof, or any other type of processor.

[0009] One or more auxiliary devices 106 include an accelerated processing device ("APD") 116. The APD 116 may be coupled to a display device. In some examples, the display device is a physical display device or a simulated device that displays output using a remote display protocol. The APD 116 is configured to receive computation commands and / or graphics rendering commands from the processor 102, process these computation and graphics rendering commands, and, in some embodiments, provide pixel output to the display device for display. As will be described in more detail below, the APD 116 includes one or more parallel processing units configured to perform computations according to a single-instruction-multiple-data ("SIMD") paradigm. Thus, although various functions are described herein as being performed by or in conjunction with the APD 116, in various alternative examples, functions described as being performed by the APD 116 may, additionally or alternatively, be performed by other computing devices having similar capabilities configured to provide graphic output to a display device, and not driven by the host processor (e.g., processor 102), at the option of choice. For example, any processing system that performs processing tasks according to the SIMD paradigm is intended to be configured to perform the functions described herein. Alternatively, a computing system that does not perform processing tasks according to the SIMD paradigm is intended to perform the functions described herein.

[0010] One or more I / O devices 117 include one or more input devices such as a keyboard, keypad, touchscreen, touchpad, detector, microphone, accelerometer, gyroscope, biometric scanner, or network connection (e.g., a wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals), and / or one or more output devices such as a display device, speaker, printer, haptic feedback device, one or more lights, antenna, or network connection (e.g., a wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals).

[0011] Figure 2 shows details of a device 100 and APD 116 in an example. The processor 102 (Figure 1) runs the operating system 120, the driver 122 (APD driver 122), and the application 126, and may also run other software alternatively or additionally. The operating system 120 controls various aspects of the device 100, such as managing hardware resources, processing service requests, scheduling and controlling process execution, and performing other operations. The APD driver 122 controls the operation of the APD 116 and sends tasks, such as graphics rendering tasks or other work, to the APD 116 for processing. The APD driver 122 also includes a just-in-time compiler that compiles programs to be executed by the processing components of the APD 116 (such as the SIMD unit 138, which will be described in more detail below).

[0012] The APD116 executes commands and programs for selected functions, such as graphics and non-graphics operations, that are suitable for parallel processing. Based on commands received from the processor 102, the APD116 can be used to perform graphics pipeline operations such as pixel operations, geometric calculations, and rendering images to a display device. In addition, based on instructions received from the processor 102, the APD116 can perform computational operations that are not directly related to graphics operations, such as operations related to video, physical simulations, computational fluid dynamics, or other tasks.

[0013] The APD116 includes a compute unit 132 which includes one or more SIMD units 138 configured to operate in parallel according to a SIMD paradigm at the request of the processor 102 (or another unit). The SIMD paradigm is one in which multiple processing elements share a single program control flow unit and program counter, and thus execute the same program, but with different data. For example, each SIMD unit 138 includes 16 lanes, and each lane executes the same instruction simultaneously with other lanes in the SIMD unit 138, but can execute that instruction with different data. Lanes can be switched off using predication if not all lanes need to execute a given instruction. Predication can also be used to execute programs with branched control flows. More specifically, for programs with conditional branches or other instructions in which the control flow is based on calculations performed by individual lanes, predication of lanes corresponding to control flow paths that are not currently being executed, and serial execution of different control flow paths, enables arbitrary control flows.

[0014] The basic unit of execution in the compute unit 132 is a work item. Each work item represents a single instantiation of a program to be executed in parallel on a specific lane. Work items can be executed simultaneously (or partially simultaneously and partially sequentially) as a “wavefront” on a single SIMD processing unit 138. One or more wavefronts constitute a “work group,” which is a collection of work items designated to run the same program. A work group can be executed by executing each of the wavefronts that make up the work group. In an alternative example, a wavefront can be executed on a single SIMD unit 138 or on different SIMD units 138. A wavefront can be thought of as the largest collection of work items that can be executed simultaneously (or pseudo-simultaneously) on a single SIMD unit 138. “Pseudo-simultaneous” execution occurs when the number of wavefronts is greater than the number of lanes in the SIMD unit 138. In such a situation, the wavefront is executed over multiple cycles, with different collections of work items executed in different cycles. The APD scheduler 136 (also referred to herein as the "command processor 136") is configured to perform operations related to scheduling various workgroup warps and wavefronts on the compute unit 132 and the SIMD unit 138.

[0015] The parallel processing provided by the computing unit 132 is suitable for graphics-related operations such as pixel value calculation, vertex transformation, and other graphics operations. Therefore, in some cases, the graphics pipeline 134, which accepts graphics processing commands from the processor 102, provides computing tasks to the computing unit 132 for parallel execution.

[0016] Additionally, the compute unit 132 is used to perform computational tasks that are not related to graphics or are not performed as part of the "normal" operation of the graphics pipeline 134 (for example, custom operations performed to supplement the operations performed on the graphics pipeline 134). An application 126 or other software running on the processor 102 sends a program that defines such computational tasks to the APD 116 for execution.

[0017] It is desirable to understand which memory accesses are occurring at a fine-grained level in real time. Computer systems often provide some visibility into which memory accesses are occurring and when. However, such visibility is usually limited by providing only an overall count of memory accesses over a long period of time. Fine-grained access information, which indicates which addresses memory accesses are directed to and when such accesses occur, is not usually provided by hardware. Such information can be extremely useful. For example, fine-grained memory access information can enable application developers to identify memory access bottlenecks in their applications at a very fine-grained level (e.g., understanding which accesses are problematic and at what time), which can then enable them to improve application performance by adjusting behavioral patterns such as memory access ordering and grouping. In another example, fine-grained memory access information can be provided to a runtime performance analyzer that can adjust execution settings based on memory access.

[0018] Logger 202 is shown in Figure 2. Although shown as part of APD116, in alternative examples, it should be understood that logger 202 is not part of APD116 but is communicatively coupled to APD116. Logger 202 is configured to store performance event information in the performance log and memory access event information in the memory access log. Memory access events include events such as writes to and reads from memory. Memory access event information implicitly or explicitly indicates the memory address associated with the memory access. In other words, the memory access log stores an indicator of which memory accesses were performed and to which memory address the memory accesses were directed. Memory address information is provided at a certain level of granularity, not necessarily to the exact address. In some examples, the memory address specifies a large chunk of memory (a range of memory addresses) where the memory access is performed, but does not provide any more specific information. Both performance event information and memory access event information include, or are associated with, a period or other ordering information indicating the "time" of the relevant performance event or memory access event. In some examples herein, this “time” is referred to as an epoch. Furthermore, performance event information for a given time includes memory access event references that point to related memory access event information for the same time. These memory access event references enable correlation between performance events and memory access events, for example, during subsequent analysis or use of performance event information and memory access event information.

[0019] As described above, performance event information for a given period includes references to memory access event information for the same period. These references allow subsequent processing to correlate performance events with memory access. Performance events can represent various aspects of performance, such as processing throughput, processing latency, memory access performance (e.g., the amount of data successfully accessed within a given time period), or other aspects. Generally, performance events indicate how well the computing device 100 is performing over a given period, and any of the various measures of such performance may be used. By associating such performance events with memory access events, subsequent analysis can first detect a performance level of interest (e.g., performance degradation), and then determine which memory accesses occurred during that period and which addresses are associated with such memory accesses. In some cases, this decision allows the analysis to determine how a particular memory access being performed results in a specific performance degradation, or, more generally, how some aspect of the memory access itself or the processing related to the memory access results in, causes, or is otherwise associated with a specific performance degradation.

[0020] Logger 202 can record which memory addresses various memory accesses target. In some examples, the address resolution for which such tracking is performed is variable by logger 202, either automatically or at the request of different units. Address resolution refers to the size of the memory access range for which logger 202 stores individual items of memory access information. For example, in a 256-byte address resolution, logger 202 stores items of memory access information for accesses within a 256-byte address range. In one example, at a first "time," logger 202 detects memory accesses to addresses within a first 256-byte range and records such memory accesses as memory access event information for the first time and the first 256 bytes. Thus, logger 202 stores information indicating that the number of detected memory accesses occurred during the first time. Information indicating which memory address within that 256-byte range the memory access occurred to is not stored. As can be seen from the diagram, address resolution indicates the specificity of how memory access events are recorded.

[0021] Logger 202 records performance events and memory access events over time. In some examples, logger 202 records a single performance event entry over a given time period and multiple memory access event entries over a given time period. Each performance event entry stores performance event information for a specific time period. Each memory access event entry stores memory access event information for a specific combination of time and memory address range. In other words, in such examples, logger 202 stores, for each time period, one item of performance event information and multiple items of memory access event information, each item of memory access event information pertaining to a different memory address range. Each item of performance event information contains a set of performance events for a time and multiple memory address ranges, and each item of memory access event information is associated with a time and memory address range and contains an indicator of which memory access to that memory address range occurred at the associated time. It should be understood that performance event information is not specific to any particular memory address range and therefore covers multiple memory address ranges (or can be thought to cover the entire memory address space).

[0022] In some cases, the memory addresses tracked by logger 202 are in the physical address space, as opposed to the virtual address space. The physical address space is the address space of the physical memory device, while the virtual address space is an address space mapped to the physical address space and therefore independent of the physical addresses of the memory device. Typically, the operating system and / or hardware (e.g., the memory controller) maintains information mapping the virtual address space to the physical address space. When an application or other software or hardware requests access to memory using a virtual address, the operating system and / or hardware translates such virtual addresses to physical addresses to access the memory.

[0023] The address range size of the memory access event information tracked by the logger 202 may be the same as or different from the virtual address memory page size. A virtual address memory page is a portion of consecutive addresses for which memory address translation is performed. More specifically, usually, a virtual address has a portion (usually the most significant bits) that can be considered as a virtual memory page address. It is this portion that is translated into a physical address memory page. Obtaining a more fine-grained physical address is done by translating the virtual memory page address into a physical memory page address and then adding an offset. The offset is the portion of the virtual memory address other than the virtual memory page address. The size of the address range may be different from or the same as this virtual memory page size.

[0024] In some examples, it is advantageous to make the trace address range size less than or equal to the virtual memory page size. This is because if the trace address range size is larger than the virtual memory page size, in any particular entry of the memory access event information, it is possible to track information from multiple unrelated virtual memory pages, which may not be desirable. That is, tracking information from multiple unrelated virtual memory pages can result in the inability to distinguish between virtual memory pages with respect to the set of states tracked in a single entry of the memory address trace information. Therefore, in some examples, the logger 202 restricts the memory address range size to be less than or equal to the virtual memory address page size.

[0025] The above states that performance information and memory access event information are tracked over a specific "time." The term "time" is broadly defined herein. Time does not necessarily refer to wall clock time, chip clock time, or any other similar measure, although in some examples, time refers to one such measure. Alternatively, "time" can be measured in relation to the number of events that have occurred and have been tracked. In one example, "time" advances as the tracked event occurs. For example, time is incremented when a memory access occurs. In another example, time is advanced for each byte of memory accessed via the data fabric (the connection between the requester and memory), or for each byte accessed within memory. In yet another example, time is advanced if the reference clock is advanced. Thus, in this example, a certain number of memory access events are stored in any particular item of the memory access event information. In other words, in some examples, logger 202 tracks a certain number of events. In other examples, a certain number of performance events are stored in any particular item of the performance event information.

[0026] In some examples, each item in the performance event information and each item in the memory access event information corresponds to an "epoch." Each epoch ends when an epoch end event occurs. In some examples, an epoch end event occurs when an item in the performance event information or an item in the memory access event information overflows. In some examples, an overflow occurs when the available storage space for an item in the performance event information or an item in the memory access event information overflows. In some examples, an overflow occurs when enough data has been tracked, and as a result, for at least one item of the tracked data, the amount of available storage space is zero or insufficient to store more data; in other words, there is no free space left in the storage space to store additional data. In some examples, the overflowing storage space can track any type of information. It should be understood that this storage space is the storage space that stores any of the data tracked by the logger. In some examples, the storage space overflows when the number of performance events or memory access events equals the maximum value of any item within a given epoch. In other examples, if the statistical count of an item in performance event information or memory access event information reaches its maximum value (for example, 255 for an 8-bit counter), the storage device overflows. In some examples, when an overflow occurs, a new epoch is started with new items in performance event information and memory access information. It should be understood that an item in memory access event information for a given address range within a given epoch may overflow before any other item in memory access event information for a different address range within the same epoch overflows. In that case, a new epoch is started for all items in both performance event information and memory access event information. In some examples, each item in performance event information contains one or more pointers to one or more items (or all items) of memory access event information within the same epoch as the item in performance event information.In some examples, a new epoch is not started and new entries of performance event information are generated in the same epoch.

[0027] FIG. 3 shows an exemplary operation performed by logger 202. Logger 202 interfaces with one or more clients 302 and one or more memories 304. Specifically, logger 202 monitors performance events of client 302 and memory 304, monitors memory accesses from client 302 to memory 304, and records such events in performance log 306 and access log 308. It should be understood that memory 304 can be any technically realizable memory, such as a cache or memory, etc., and can be on the same chip or a different chip from logger 202, processor 102, or APD 116. In some examples, logger 202 exists for multiple memory elements of a memory hierarchy (i.e., for each cache, each memory, etc.). In some examples, logger 202 tracks events for multiple memories (e.g., for one or more caches, and / or for one or more memories or other entities). In some such examples, each memory access log entry stores statistics for multiple memories / caches. In other such examples, each memory access log entry is dedicated to a single memory or cache type, and each such memory access log entry includes metrics for the associated memory type.

[0028] In some examples, client 302 is any unit of device 100 that can request memory access. In some examples, such units include processor 102 and APD 116, as well as any other units that can request memory access, such as auxiliary processor 114 or I / O device 17. In various examples, logger 202 is embodied as hardware (e.g., circuitry configured to perform the operations described herein), software running on a processor, or a combination thereof. In some examples, logger 202 is partially or completely implemented by command processor 136. In some examples, command processor 136 is a programmable processor that runs software performing some or all of the functions of logger 202.

[0029] When logger 202 monitors performance events and memory access events, logger 202 generates performance log entries 322 and memory access log entries 324. In some examples, performance log entry 322 is the performance event information item described above. In some examples, memory access log entry 324 is the memory access event information item described above. Logger 202 observes performance events and memory access events, extracts or generates information about such events, and writes such information to performance log entries 322 and memory access log entries 324, as described elsewhere in this specification.

[0030] Each performance log entry 322 includes a time range 326, statistics 328, and one or more pointers to a memory access log 330. In some examples, the time range includes measuring actual time (e.g., wall clock time), measuring system clock time (e.g., number of cycles from the initial point), or including a reference clock index based on the system clock time of any clock in device 100. Note that this time range 326 is not necessarily the same type of time as the time that defines which “epoch” the entry is in, since epochs can be based on the ordering of performance events or memory access events. Explicitly storing the time range 326 in the performance log entry 322 provides the ability to link a particular epoch to an actual point in time.

[0031] Statistics 328 include information about performance events being tracked. Some exemplary statistics are for a given epoch (e.g., occurring within that epoch) and include the number of bytes of data fabric written to or read for one or more memory types (e.g., cache, memory, or other memory types), the number of bytes written to, read from, and / or prefetched to each such memory type, the number of read instances and bytes involved in compressed read / modify / write operations, the number of bytes of compressed metadata read from or written to memory, the number of burst writes or reads, the amount of bandwidth used by one or more of the memory, cache, or data fabric (e.g., as a percentage), power management events, and user-defined events that can be defined by entities such as software. Performance log entries 322 include one or more of these items of statistics.

[0032] The number of bytes written to or read from the data fabric includes the number of bytes written to or read using the data fabric. The data fabric is the connection between client 302 and memory 304. The data fabric may have a capacity (e.g., bandwidth) independent of the capacity of the memory or client from which data is written or read, and therefore the ability to measure the number of bytes written to or read may be useful to understand. The number of bytes read to or written to one or more memory types is stored per memory type. In one example, the number of bytes read from or written to the cache in an epoch is stored in the statistics of a particular entry 322, and the number of bytes read from or written to memory in the same epoch is also stored in the statistics of that entry 322. In some examples, memory access is accessed on compressed data, and compression is a hardware-supported operation. In some such examples, logger 202 maintains separate records of the number of bytes read to, written to, or modified for compressed and uncompressed data. Therefore, in some such examples, the statistics 328 for a particular entry 322 include the number of bytes read, written, or modified for uncompressed data within an epoch, and the number of bytes read, written, or modified for compressed data within the same epoch. In addition, compressed data may contain or request additional metadata that specifies the information necessary to compress or decompress the data, or that is useful for the compression operation. In some examples, statistics 328 stores the amount of such metadata stored in the epoch. In some examples, memory accesses are of burst type and non-burst type. Generally, burst type accesses are accesses to relatively large amounts of data consecutively in the physical address space, while non-burst type accesses are accesses to individual data items (e.g., individual words). In some examples, statistics 328 stores a separate count of burst type accesses in addition to the count of non-burst type accesses.Bandwidth information includes the percentage (or other measure) of bandwidth capacity actually used for memory or data fabric within the mentioned epoch.

[0033] For any given performance log entry 322 of a particular epoch, a pointer to the access log 330 includes a pointer to the access log entry 324 of that epoch. In some examples, a single performance log entry 322 of an epoch includes pointers to all access log entries 324 in the access log 308 of that same epoch. Each access log entry 324 includes an access log entry address 332 and access log statistics 334. The access log entry address 332 of an access log entry 324 specifies the address range of the statistics 334 of that access log entry 324. More specifically, the entire access log 308 has an address range size (the "address resolution" described above) that specifies the granularity at which memory accesses are tracked. This address range size also indicates the range of memory addresses after the access log entry address 332 that are tracked by the access log entry 324. In other words, each access log entry 324 tracks addresses between the access log entry address 332 and the access log entry address 332 added to the address range size. Statistics 334 contain information about memory accesses tracked within the corresponding address range specified by the access log entry 332. The epoch performance log entry 322 contains statistics 328 for multiple different address ranges occurring within the epoch, and each such address range will have a different access log entry 324, each of which will contain statistics 334 for memory accesses made to the address range within the epoch.

[0034] Statistics 334 include, for all epochs and memory address ranges of access log entries 324, the number of bytes returned via the data fabric, the number of bytes overwritten on the data fabric, the read compression ratio, the write compression ratio, the number of bytes written to or read from memory (such numbers may be stored independently for different types of memory, such as memory, cache, or other types of memory), the number of bytes prefetched into memory, the number of bytes rinsed (where rinsing means writing dirty data back to auxiliary memory so that the data is no longer dirty), the number of reads caused by compression operations, the number of atomic memory operations performed, the cache policy (for example, if an allocation occurs to store the missed data in the cache in the event of a miss, this includes whether an allocation to the cache is allowed, and rereference interval prediction data indicating the amount of "time" between cache line rereferences), user-defined data, or any combination of any other types of information that may be stored. The read compression ratio is the ratio of the size of compressed data to the size of uncompressed data for read operations, and the write compression ratio is the ratio of the size of compressed data to the size of uncompressed data for write operations. The number of reads caused by a compression operation includes the number of reads for data actually generated as a result of the compression operation. For example, reading from or writing to compressed data may require reading or writing data other than the actual compressed data, and this other data may include compression metadata or other data in the compressed block (because the data may be compressed together, and therefore an operation on a portion of the compressed data may require other operations on the other data that is compressed together).

[0035] The log data consumer 310 is also shown in Figure 3. These log data consumers 310 include one or more log data backup agents and / or log data analyzers, any of which are embodied as hardware (e.g., circuitry), software running on a processor, or a combination thereof. The log data backup agent stores information from the performance log 306 and / or access log 308 in one or more backup memories. In some examples, this storage does not trigger any logging by itself. One or more backup memories include one or more of memory 104, memory in APD 116, storage device 108, or other memories. The log data backup agent transfers data from the performance log 306 and / or access log 308 when either the performance log 306 and / or access log 308 runs out of space (e.g., a new entry is generated but there is no space left), or in response to any other technically feasible event. The log data analyzer analyzes the performance log 306 and / or access log 308. In some examples, the log data analyzer analyzes these logs to determine how to adjust the operation of the device 100 for better performance, and / or analyzes these logs to generate and provide conditional information for consumption by another system or for human use (e.g., for human developers developing applications, using profiling data to improve application performance). In some examples, the log data analyzer is embodied as multiple parallel programs (e.g., compute shader programs running on the APD 116). The data in the performance log 306 and access log 308 are organized to facilitate efficient parallel processing of such data. In one example, one parallel execution item (e.g., a first compute shader work item or wavefront) analyzes the first access log entry 324 while a second parallel execution item analyzes the second access log entry 324.Both of these parallel execution items generate the results of such analysis in parallel, which are then used by different execution items (such as a compute shader work item or wavefront, or a thread on processor 102). In some examples, different parallel execution items analyze the performance log 322 in parallel with both the first and second parallel execution items. In some examples, a parallel execution item analyzes the performance log entry 322, fetches the pointer 330, and generates further parallel execution items to analyze the access log entry 324 pointed to by the pointer 330, along with the information from the analysis of the performance log entry 322. In some examples, a single execution item processes information within multiple access log entries 324 or information derived from multiple access log entries 324. In some examples, a single execution item processes information from different epochs. In some such examples, a single execution item aggregates information from different epochs, for example, by combining statistics from a smaller address range and a single epoch to generate statistics from a larger address range and a longer epoch.

[0036] In some cases, logger 202 filters information, preventing it from being written to performance log 306 and / or access log 308. In some such cases, logger 202 refers to data indicating processes, virtual machines, or other entities that are permitted to log, and ignores (does not log) access that is not permitted to log. In one example, an application with logging disabled performs memory access, but logger 202 does not include information about such memory access in performance log 306 and / or access log 308.

[0037] Figure 4 is a flowchart illustrating an example of a method 400 for performing performance-related and memory-related operations. While the system is described in Figures 1 to 3, those skilled in the art will understand that any system configured to perform the steps of method 400 in any technically feasible order is included in the scope of this disclosure.

[0038] In step 402, the logger 202 observes the behavior of one or more clients 302 and / or one or more memory 304. The behavior includes one or more of the behaviors described above with respect to the information stored in the performance log 306 and / or access log 308. In step 404, the logger 202 generates entries in either or both of the performance log 306 and / or access log 308 based on the observed behavior. In some examples, the logger 202 operates on an epoch. An epoch is a certain amount of “time,” which is measured as described herein. As described elsewhere herein, an epoch begins after the previous epoch has ended and ends when an epoch end event occurs. When an epoch end event occurs, the logger 202 generates an entry in the performance log 306 and one or more entries in the access log 308. As described elsewhere in this specification, the generated performance log entry 322 includes epoch statistics 328 and a pointer to one or more access log entries 324, each of which is associated with a memory address range and includes statistics 334 for that memory address range. In step 406, the logger 202 writes the log entries (e.g., performance log entry 322 and memory access log entry 324) to auxiliary storage. In some examples, this operation occurs when a new entry is logged and there is insufficient free space for such entries, or on any technically feasible trigger, such as periodic. One or more log data consumers 310 can process the information from the performance log 306 and access log 308 within those logs or after such information has been written to auxiliary storage. In various cases, the performance log 306 and access log 308 are stored in the logger 202's memory, memory dedicated to the logger 202, or more generally, memory shared with other units (such as the general-purpose memory of the APD116). The auxiliary storage device acts as a larger overall memory for log entries and therefore provides memory for such entries even when the performance log 308 and access log 308 no longer have the capacity for entries.

[0039] Various functional units shown in the figures and / or described herein (including, but not limited to, the processor 102, auxiliary device 106, auxiliary processor 114, APD 116, I / O device 117, scheduler 136, compute unit 132, SIMD unit 138, logger 202, client 302, memory 304, and log data consumer 310) can be stored in a non-temporary computer-readable medium or another medium as a general-purpose computer, processor, processor core, or fixed functional circuit, and can be implemented as a program, software, or firmware executable by a general-purpose computer, processor, or processor core, or as a combination of software executed on a processor or fixed functional circuit. The methods provided can be implemented in a general-purpose computer, processor, or processor core. Suitable processors include, by example, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines. Such processors may be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data, including netlists (such as instructions that can be stored in a computer-readable medium). The results of such processing may be maskwork, which is then used in a subsequent semiconductor manufacturing process to manufacture a processor that implements the features of the present disclosure.

[0040] The methods or flowcharts provided herein may be implemented in computer programs, software, or firmware embedded in a non-temporary computer-readable storage medium for execution by a general-purpose computer or processor. Examples of non-temporary computer-readable storage media include magnetic media such as read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, as well as magnetic-optical media such as CD-ROM disks and digital versatile disks (DVDs).

Claims

1. It is a method, Generate multiple performance log entries based on observed behavior, This includes generating multiple memory access log entries based on the observed behavior, Each of the aforementioned performance log entries is associated with one or more of the aforementioned memory access log entries. Each of the aforementioned performance log entries is associated with an epoch, Each memory access log entry is associated with an epoch and a memory address range. method.

2. Each of the aforementioned performance log entries includes a set of performance statistics, The method according to claim 1.

3. The set of performance statistics includes information about the amount of data read from memory or written to memory within an epoch. The method according to claim 2.

4. The set of performance statistics includes information about memory or data fabric bandwidth utilization within an epoch. The method according to claim 2.

5. The performance log entry includes, with respect to the performance log entry associated with the epoch, one or more pointers that point to one or more memory access log entries of the epoch. The method according to claim 1.

6. Multiple compute unit execution items include processing multiple memory access log entries of the multiple performance log entries in parallel, The method according to claim 1.

7. Processing the aforementioned multiple memory access logs in parallel includes analyzing the aforementioned multiple memory access logs to identify changes in operation and improve performance. The method according to claim 6.

8. Each memory access log entry includes statistics for memory access within the memory address range and statistics for the epoch associated with the memory access log entry. The method according to claim 1.

9. This includes storing each memory access log entry and each performance log entry in an auxiliary storage device. The method according to claim 1.

10. It is a system, Computation system and, Equipped with a logger, The aforementioned logger, Generate multiple performance log entries based on observed behavior, Based on the observed behavior, multiple memory access log entries are generated, It is configured to do the following: Each of the aforementioned performance log entries is associated with one or more of the aforementioned memory access log entries. Each of the aforementioned performance log entries is associated with an epoch, Each memory access log entry is associated with an epoch and a memory address range. system.

11. Each of the aforementioned performance log entries includes a set of performance statistics, The system according to claim 10.

12. The set of performance statistics includes information about the amount of data read from memory or written to memory within an epoch. The system according to claim 11.

13. The set of performance statistics includes information about memory or data fabric bandwidth utilization within an epoch. The system according to claim 11.

14. The performance log entry includes, with respect to the performance log entry associated with the epoch, one or more pointers that point to one or more memory access log entries of the epoch. The system according to claim 10.

15. The processor comprises a processor configured to execute multiple compute unit execution items, each configured to process multiple memory access log entries of the multiple performance log entries in parallel. The system according to claim 10.

16. Processing the aforementioned multiple memory access logs in parallel includes analyzing the aforementioned multiple memory access logs to identify changes in operation and improve performance. The system according to claim 15.

17. Each memory access log entry includes statistics for memory access within the memory address range and statistics for the epoch associated with the memory access log entry. The system according to claim 10.

18. The logger is configured to store each memory access log entry and each performance log entry in an auxiliary storage device. The system according to claim 10.

19. A computer-readable storage medium for storing information, When the aforementioned information is executed by the processor, Generate multiple performance log entries based on observed behavior, Based on the observed behavior, multiple memory access log entries are generated, The processor is made to perform an operation that includes the following: Each of the aforementioned performance log entries is associated with one or more of the aforementioned memory access log entries. Each of the aforementioned performance log entries is associated with an epoch, Each memory access log entry is associated with an epoch and a memory address range. Computer-readable storage medium.

20. The aforementioned operation includes storing each memory access log entry and each performance log entry in an auxiliary storage device. A computer-readable storage medium according to claim 19.

Images