Performance and memory access tracking

Abstract

Techniques for performing memory operations are disclosed herein. The techniques include generating a plurality of performance log entries based on observed operations; and generating a plurality of memory access log entries based on the observed operation, where each performance log entry of the plurality of performance log entries is associated with one or more memory access log entries of the plurality of memory access log entries, where each performance log entry is associated with a period; and wherein each memory access log entry is associated with a period and a memory address range.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to pending U.S. nonprovisional patent application No. 18 / 192,694, filed March 30, 2023, entitled “Performance and Memory Access Tracking,” the entire contents of which are incorporated herein by reference. Background Technology

[0003] Computational performance is partly dependent on memory performance. Therefore, computational performance can be improved by optimizing memory access. Furthermore, increasingly specific insights into memory access performance can, at least theoretically, provide ever-increasing capabilities for performance improvements. However, attempting to gain such specific insights can itself negatively impact performance, potentially skewing measurements and leading to inaccurate results. Performance analysis is constantly being improved. Attached Figure Description

[0004] A more detailed understanding can be obtained from the following description, which is given with examples and accompanying figures, wherein:

[0005] Figure 1 It is a block diagram of an exemplary device that can implement one or more features of this disclosure;

[0006] Figure 2 An example is shown based on the example. Figure 1 Details of the equipment;

[0007] Figure 3 Exemplary operations for a recorder are illustrated; and

[0008] Figure 4 This is a flowchart of a method for performing memory operations, based on an example. Detailed Implementation

[0009] This document discloses techniques for performing profiling operations. These techniques include generating multiple performance log entries based on observed operations; and generating multiple memory access log entries based on observed operations, wherein each of the multiple performance log entries is associated with one or more memory access log entries, wherein each performance log entry is associated with a period; and wherein each memory access log entry is associated with a period and a memory address range.

[0010] Figure 1This is a block diagram of an exemplary computing device 100 that can implement one or more features of this disclosure. In various examples, computing device 100 is, for example, a computer, gaming device, handheld device, set-top box, television, mobile phone, tablet computer, or other computing device, but not limited to these. Device 100 includes, but is not limited to, one or more processors 102, memory 104, one or more auxiliary devices 106, and storage device 108. Interconnectors 112, which may be buses, combinations of buses, and / or any other communication components, communicatively link one or more processors 102, memory 104, one or more auxiliary devices 106, and storage device 108.

[0011] 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, wherein each processor core may be a CPU, GPU, or neural processor. In various alternatives, at least a portion of memory 104 is located on the same die as one or more of the processors 102, such as on the same chip or in an interpolator arrangement, and / or at least a portion of memory 104 is located separately from one or more processors 102. Memory 104 includes volatile or non-volatile memory, such as random access memory (RAM), dynamic RAM, or cache.

[0012] Storage device 108 includes fixed or removable storage devices, such as, but not limited to, hard disk drives, solid-state drives, optical disk drives, or flash drives. 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 (“I / O”) devices. Auxiliary processor 114 includes, but is not limited to, processing units capable of executing instructions, such as central processing units, graphics processing units, parallel processing units capable of performing computational shader operations in single-instruction multiple-data (SIM), multimedia accelerators such as video encoding or decoding accelerators, 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 circuitry, a combination thereof, or any other type of processor.

[0013] One or more auxiliary devices 106 include an accelerated processing device (“APD”) 116. The APD 116 may be coupled to a display device, which in some examples is a physical display device or an analog device that uses a remote display protocol to display output. The APD 116 is configured to receive computation commands and graphics rendering commands from the processor 102, process those computation and graphics rendering commands, and, in some specific implementations, provide pixel output to the display device for display. As detailed below, the APD 116 includes one or more parallel processing units configured to perform computations according to a single instruction multiple data (“SIMD”) paradigm. Therefore, although various functions are described herein as being performed by or in conjunction with the APD 116, in various alternatives, functions described as being performed by the APD 116 are additionally or alternatively performed by other computing devices with similar capabilities, which are not driven by a host processor (e.g., processor 102) and are optionally configured to provide graphics output to the display device. For example, it is conceivable that any processing system performing processing tasks according to the SIMD paradigm could be configured to perform the functions described herein. Alternatively, it is conceivable that a computing system performing processing tasks not according to the SIMD paradigm could perform the functions described herein.

[0014] 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 LAN 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 LAN card for transmitting and / or receiving wireless IEEE 802 signals).

[0015] Figure 2 Details of the device 100 and APD 116 according to the example are illustrated. Processor 102 ( Figure 1 The device 100 executes an operating system 120, a driver 122 (“APD driver 122”), and an application program 126, and alternatively or additionally, may also execute other software. The operating system 120 controls various aspects of the device 100, such as managing hardware resources, handling service requests, scheduling and controlling process execution, and performing other operations. The APD driver 122 controls the operation of the APD 116, sending tasks such as graphics rendering tasks or other jobs to the APD 116 for processing. The APD driver 122 also includes a just-in-time compiler that compiles programs for execution by the processing units of the APD 116, such as the SIMD unit 138 detailed below.

[0016] APD 116 executes commands and procedures for selected functions, such as graphics and non-graphics operations suitable for parallel processing. APD 116 can be used to perform graphics pipeline operations, such as pixel manipulation, geometric calculations, and rendering images to a display device based on commands received from processor 102. APD 116 also performs computational processing operations not directly related to graphics operations based on commands received from processor 102, such as operations related to video, physics simulations, computational fluid dynamics, or other tasks.

[0017] APD 116 includes a computation unit 132 comprising one or more SIMD units 138 configured to perform operations in parallel upon request from processor 102 (another unit) according to a SIMD paradigm. A SIMD paradigm is a paradigm in which multiple processing elements share a single program control flow unit and program counter and thereby execute the same program, but are able to execute the program with different data. In one example, each SIMD unit 138 includes sixteen channels, where each channel executes the same instruction simultaneously with other channels in the SIMD unit 138, but can execute the instruction with different data. If not all channels need to execute a given instruction, channels can be shut down by prediction. Prediction can also be used to execute programs with divergent control flow. More specifically, for programs with conditional branches or other instructions where the control flow is based on computations executed by a single channel, prediction corresponds to channels of control flow paths that are not currently being executed, and the serial execution of different control flow paths can achieve arbitrary control flow.

[0018] The basic unit of execution in computing unit 132 is a work item. Each work item represents a single instantiation of a program to be executed in parallel on a specific channel. Work items can be executed simultaneously (or partially simultaneously and partially sequentially) as “wavefronts” on a single SIMD processing unit 138. One or more wavefronts are included in a “workgroup”, which comprises a set of work items designated to execute the same program. A workgroup can be executed by executing each of the wavefronts that constitute the workgroup. Alternatively, wavefronts may be executed on a single SIMD unit 138 or on different SIMD units 138. A wavefront can be considered as the largest set 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 channels in SIMD unit 138. In this case, the wavefronts are executed over multiple cycles, with different sets of work items executed in different cycles. APD scheduler 136 (sometimes referred to herein as “command processor 136”) is configured to perform operations related to scheduling the various workgroups and wavefronts on computing unit 132 and SIMD unit 138.

[0019] The parallelism 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 instances, the graphics pipeline 134, which receives graphics processing commands from the processor 102, provides computational tasks to the computing unit 132 for parallel execution.

[0020] The computing unit 132 is also used to perform computational tasks that do not involve graphics or are not part of the “normal” operation of the graphics pipeline 134 (e.g., custom operations performed to supplement the processing performed for the operation of the graphics pipeline 134). An application program 126 or other software executing on the processor 102 transfers programs defining such computational tasks to the APD 116 for execution.

[0021] The desire is to understand, in real time, what memory accesses are occurring at a fine-grained level. Computer systems typically provide some degree of visibility into what memory accesses are happening and when they occur. However, such visibility is often limited, such as by providing only an overall count of memory accesses over long periods of time. Fine-grained access information, indicating which addresses memory accesses are routed to and when such accesses are made, is typically not provided by the hardware. Such information can be extremely useful. For example, fine-grained memory access information can allow application developers to identify memory access bottlenecks in their applications at a very fine-grained level (e.g., to understand which accesses are problematic at which times), which can allow application developers to improve application performance by tweaking aspects of operations such as the ordering of memory accesses, the grouping of memory accesses, etc. In another example, fine-grained memory access information can be provided to a runtime performance analyzer, which can then adjust execution settings based on memory accesses.

[0022] Recorder 202 in Figure 2The following example is provided. Although illustrated as part of APD 116, it should be understood that in alternative examples, logger 202 is not part of APD 116 and is communicatively coupled to APD 116. Logger 202 is configured to store performance event information in a performance log and memory access event information in a 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 indication of what memory access was performed and to what memory address the memory access was directed. The memory address information is provided at a certain granularity, which is not necessarily an exact address. In some examples, the memory address specifies a large block of memory (a range of memory addresses) where the memory access was performed, but does not provide more specific information than that. Both performance event information and memory access event information include or are associated with time periods or other sorting information that indicates the "time" of the associated performance event or memory access event. In some instances of this document, the “time” is referred to as a period. Additionally, performance event information for a specific time includes memory access event references pointing to associated memory access event information for that same time. These memory access event references allow, for example, the association of performance events with memory access events during subsequent analysis or use of the performance event information and memory access event information.

[0023] As described above, performance event information for a specific time period includes references to memory access event information for the same time period. These references allow subsequent processing to correlate performance events with memory accesses. Performance events can indicate 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 performs within a given time period, and any of the various metrics for such performance can be used. Correlating such performance events with memory access events allows subsequent analysis to first detect the performance level of interest (e.g., performance degradation) and then determine which memory accesses occurred during that time period and which addresses were associated with such memory accesses. In some examples, this determination allows analysis to determine how certain memory accesses were performed that caused a specific performance degradation, or more generally, to determine that the memory access itself or certain aspects of the processing associated with the memory access caused, were caused by, or were otherwise associated with a specific performance degradation.

[0024] Recorder 202 is capable of recording which memory addresses various memory accesses target. In some examples, recorder 202 automatically or upon request from different units may change the address resolution at which such tracking occurs. Address resolution refers to the size of the memory access range for which recorder 202 stores individual items of memory access information. For example, using a 256-byte address resolution, recorder 202 stores items of memory access information for accesses within a 256-byte address range. In the example, for a first "time," recorder 202 detects a memory access to an address within a first 256-byte range and records such a memory access as memory access event information for the first time and for the first 256 bytes. Therefore, recorder 202 stores information indicating the number of times the detected memory accesses have occurred during the first time period. No information indicating which memory addresses within that 256-byte range the memory accesses occurred is stored. It can be seen that address resolution indicates the specificity of recording memory access events.

[0025] Logger 202 records performance events on a per-time basis and also records memory access events on a per-time basis. In some examples, logger 202 records a single performance event entry for a given time and multiple memory access event entries for a given time. Each performance event entry stores performance event information for a specific time. 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 an example, logger 202 stores one item of performance event information and multiple items of memory access event information each time, where each item of memory access event information is for a different memory address range. Each item of performance event information includes a set of performance events for time and for multiple memory address ranges, and each item of memory access event information is associated with time and memory address range and includes an indication of which memory accesses occurred for that memory address range during the associated time. It should be understood that the performance event information is not specific to any memory address range and therefore covers multiple memory address ranges (or can be considered to cover the entire memory address space).

[0026] In some examples, the memory addresses tracked by logger 202 are in the physical address space, not the virtual address space. The physical address space is the address space of the physical memory device, while the virtual address space is the address space mapped to the physical address space and is 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 a virtual address into a physical address to access the memory.

[0027] The address range of memory access event information tracked by recorder 202 can be the same as or different from the virtual address memory page size. A virtual address memory page is a contiguous address for which memory address translation occurs. More specifically, typically, a virtual address has a portion (usually the most significant bit) that is considered a virtual memory page address. It is this portion that is translated into a physical address memory page. A finer-grained physical address is obtained 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 excluding the virtual memory page address. The size of the address range can be different from or the same as the virtual memory page size.

[0028] 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 greater than the virtual memory page size, it would be possible to trace information from multiple unrelated virtual memory pages in any particular item of memory access event information, which could be undesirable. That is, tracing information from multiple unrelated virtual memory pages could result in the inability to distinguish between virtual memory pages in an aggregated state that are traced in a single item of memory address trace information. Therefore, in some examples, the recorder 202 restricts the memory address range size to be equal to or less than the virtual memory address page size.

[0029] The above describes the tracking of performance information and memory access event information for a specific “time”. The term “time” is defined broadly in this document. Time does not necessarily refer to wall clock time or chip clock time or some other similar metric, although in some examples, time does refer to such a metric. Alternatively, “time” can be measured by its relationship to the number of tracked events that occur. In the examples, “time” advances as the tracked events occur. For example, time increments when a memory access occurs. In another example, time is advanced for each byte of memory accessed through a data structure (the connection between the requester and memory) or for each byte accessed in memory. In yet another example, time is advanced where the reference clock is advanced. Therefore, in this example, a certain number of memory access events are stored in any specific item of the memory access event information. In other words, in some examples, recorder 202 tracks a certain number of events. In another example, a certain number of performance events are stored in any specific item of the performance event information.

[0030] In some examples, each item of performance event information and each item of memory access event information corresponds to a "period". Each period ends when a period-end event occurs. In some examples, a period-end event occurs when an item of performance event information overflows or when an item of memory access event information overflows. In some examples, an overflow occurs when the available storage space in an item of performance event information or memory access event information overflows. In some examples, an overflow occurs for at least one item of tracked data when enough data has been tracked such that the amount of available storage is zero or insufficient to store more data—in other words, when there is no remaining space in the storage device to store additional data. In some examples, the overflowing storage device can track any type of information. It should be understood that the storage device is the storage device that stores any data tracked by the logger. In some examples, a storage device overflows when the number of performance events or memory access events equals the maximum value of any item in a given period. In other examples, a storage device overflows when the count of the statistics for an item of performance event information or memory access event information reaches a maximum value (e.g., 255 for an 8-bit counter). In some examples, when an overflow occurs, a new period begins with new items containing 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 period can overflow before any other item in memory access event information for a different address range within the same period overflows. In this instance, the new period begins for both the performance event information and all items in the memory access event information. In some examples, each item in the performance event information includes one or more pointers to one or more items (or all items) in the memory access event information within the same period as the item in the performance event information. In some examples, no new period begins, and new items in the performance event information are created within the same period.

[0031] Figure 3An exemplary operation performed by logger 202 is illustrated. Logger 202 interfaces with one or more clients 302 and one or more memories 304. Specifically, logger 202 monitors performance events of clients 302 and memories 304, monitors memory accesses from clients 302 to memories 304, and logs these events in performance log 306 and access log 308. It should be understood that memories 304 are any technically feasible memory, such as cache or memory, and such as memory on the same chip as logger 202, processor 102, or APD 116 or on a different chip. In some examples, there are multiple memory elements for the memory hierarchy (i.e., for each cache, each memory, etc.). In some examples, logger 202 tracks events for multiple memories (e.g., one or more caches and / or 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 contains an indication of the associated memory type.

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

[0033] When logger 202 monitors performance events and memory access events, it generates performance log entry 322 and memory access log entry 324. In some examples, performance log entry 322 is an item from the performance event information discussed above. In some examples, memory access log entry 324 is an item from the memory access event information described above. Logger 202 observes performance events and memory access events, extracts or generates information about such events, and writes such information into performance log entry 322 and memory access log entry 324, as described elsewhere herein.

[0034] Each performance log entry 322 includes a time range 326, statistics 328, and one or more pointers to the memory access log 330. In some examples, the time range includes an indication of a reference clock that measures actual time (e.g., wall clock time) or system clock time (e.g., the number of cycles since the initial point) or system clock time based on any clock of device 100. It should be noted that the time range 326 is not necessarily the same type of time as defining which "period" the entry falls within, as periods can be based on the order 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 specific period to an actual point in time.

[0035] Statistics 328 include information about the tracked performance events. Some exemplary statistics are specific to a given period (e.g., those occurring within that period) and include: the number of bytes of data structures written or read for one or more memory types (e.g., cache, memory, or other memory types); the number of bytes written to each such memory type; the number of bytes 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 compressed metadata bytes read from or written to memory; the number of burst writes or reads; the amount of bandwidth (e.g., percentage) used for one or more of the memory, cache, or data structures; power management events; and user-defined events that may be defined by an entity such as software. Performance log entries 322 include one or more of the items in the statistics.

[0036] The number of bytes written or read from the data structure includes the number of bytes written or read using the data structure. The data structure is the connection between client 302 and memory 304. The data structure may have a capacity (e.g., bandwidth) independent of the capacity of the memory or client on which the data is written or read, and therefore the ability to measure the number of bytes written or read can aid in understanding. The number of bytes read or written for one or more memory types is stored on a per-memory basis. In the example, the number of bytes read from or written to the cache during a period is stored in the statistics of a specific entry 322, and the number of bytes read from or written to memory during the same period is also stored in the statistics of that entry 322. In some examples, memory access is accessed to compressed data, where compression is a hardware-supported operation. In some such examples, recorder 202 maintains the number of bytes read, written, or modified for compressed data and uncompressed data, respectively. Therefore, in some such examples, the statistics 328 of a specific entry 322 include the number of bytes read, written, or modified for uncompressed data during a period, and the number of bytes read, written, or modified for compressed data during the same period. Additionally, compressed data may include or require additional metadata that specifies information needed to compress or decompress the compressed data or otherwise is useful for the compression operation. In some examples, statistics 328 stores the amount of such metadata stored in a period. In some examples, memory accesses are burst-type and non-burst-type. Typically, burst-type accesses are accesses to a relatively large amount of data that is contiguous 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 a count of non-burst-type accesses. Bandwidth information includes the percentage (or other metric) of bandwidth capacity actually used for memory or data structures during the mentioned period.

[0037] For any given performance log entry 322 for a specific period, the pointer to the access log 330 includes a pointer to the access log entry 324 for that period. In some examples, a single performance log entry 322 for a period includes pointers to all access log entries 324 for the same period in the access log 308. Each access log entry 324 includes an access log entry address 332 and access log statistics 334. The access log entry address 332 of the access log entry 324 specifies the address range of the statistics 334 for that access log entry 324. More specifically, the entire access log 308 has an address range size (the “address resolution” mentioned above) that specifies the granularity of tracking memory accesses. This address range size also indicates the range of memory addresses following the access log entry address 332 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. The statistics 334 include information about memory accesses tracked within the corresponding address range specified by the access log entry 332. It should be noted that the performance log entry 322 for a period includes statistics 328 about multiple different address ranges that occurred during the period, and each such address range has a different access log entry 324, each access log entry including statistics 334 about memory accesses performed on the address range during the period.

[0038] Statistics 334 include any combination of the following items for all periods and memory address ranges used to access log entries 324: the number of bytes returned by the data structure, the number of bytes written by the data structure, read compression ratio, write compression ratio, the number of bytes written to or read from memory (this number may be stored independently for different types of memory, such as RAM, cache, or other types of memory), the number of bytes prefetched into memory, the number of flushed bytes (where flushing means writing dirty data back to backing memory so that the data is no longer dirty), the number of reads caused by compression operations, the number of atomic memory operations performed, caching policies (including, for example, whether allocation to the cache is allowed, allocation occurring when a miss occurs so that the missed data is stored in the cache, rereference interval prediction data, which indicates the amount of "time" between rereferences of cache lines), user-defined data, or any other type of information that can be stored. The read compression ratio is the ratio of the size of compressed data used for read operations to the size of uncompressed data, and the write compression ratio is the ratio of the size of compressed data used for write operations to the size of uncompressed data. The number of reads caused by compression operations includes the number of times data is actually read due to the compression operation. For example, reading from or writing compressed data may require reading or writing data other than the actual compressed data, and this other data may include compressed metadata or other data in the compressed block (because data can 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).

[0039] Log data consumer 310 is also Figure 3Examples are provided below. These log data consumers 310 include one or more of a log data backup agent and / or a log data analyzer, any of which is embodied in hardware (e.g., circuitry), software executing on a processor, or a combination thereof. The log data backup agent stores information from performance log 306 and / or access log 308 into one or more backup memories. In some examples, this storage itself does not trigger any logging. The one or more backup memories include one or more of memory 104, memory within APD 116, storage device 108, or other memory. When either performance log 306 and / or access log 308 runs out of space (e.g., when a new entry needs to be created but there is no space remaining), or in response to any other technically feasible event, the log data backup agent transfers data from these logs. The log data analyzer analyzes performance log 306 and / or access log 308. In some examples, the log data analyzer analyzes these logs to determine how to tune the operation of device 100 for better performance, and / or analyzes these logs to generate and provide tuned information for use by another system or a human (e.g., a human developer developing an application who will use the profile data to improve the application's performance). In some examples, the log data analyzer is embodied as multiple parallel programs (such as compute shader programs executing on APD 116). The data in performance log 306 and access log 308 are organized to facilitate efficient parallel processing of such data. In an example, a parallel execution (e.g., a first compute shader work item or wavefront) analyzes the first access log entry 324 during the time period during which the second parallel execution analyzes the second access log entry 324. Both parallel executions produce the results of this analysis in parallel, which are used by different executions (such as compute shader work items or wavefronts or even threads on processor 102). In some examples, different parallel executions also analyze performance log 322 in parallel with the first and second parallel executions. In some examples, a parallel execution item analyzes performance log entry 322, obtains pointer 330, and generates further parallel execution items to analyze access log entry 324 pointed to by pointer 330, as well as the information analyzed from performance log entry 322. In some examples, a single execution item processes information from multiple access log entries 324 or information derived from multiple access log entries. In some examples, a single execution item processes information from different periods. In some such examples, a single execution item aggregates information from different periods, for example, by combining statistics from a smaller address range and a single period to generate statistics from a larger address range and a longer period.

[0040] In some examples, logger 202 filters information to prevent it from being written to performance log 306 and / or access log 308. In some such examples, logger 202 references data from processes, virtual machines, or other entities that are allowed to be logged and ignores (does not log) accesses that are not allowed to be logged. In the example, an application that has disabled logging has made memory accesses, but logger 202 does not include information about such memory accesses in performance log 306 and / or access log 308.

[0041] Figure 4 This is a flowchart of method 400 for performing performance-related and memory-related operations, based on an example. Although relative to... Figures 1 to 3 The system described herein is provided, but those skilled in the art will understand that any system configured to perform the steps of method 400 in any technically feasible order falls within the scope of this disclosure.

[0042] At step 402, logger 202 observes operations of one or more clients 302 and / or one or more memories 304. Operations include one or more of the operations described above with respect to information stored in performance log 306 and / or access log 308. At step 404, logger 202 generates entries for either or both of performance log 306 and access log 308 based on the observed operations. In some examples, logger 202 operates based on periods. A period is a quantity of “time” that is measured as described herein. As described elsewhere herein, a period begins after the end of a previous period and ends when a period-end event occurs. When a period-end event occurs, logger 202 generates entries for performance log 306 and one or more entries for access log 308. As described elsewhere herein, the generated performance log entries 322 include statistics 328 for the period and pointers to one or more access log entries 324, each access log entry being associated with a memory address range and including statistics 334 for that memory address range. At step 406, logger 202 writes log entries (e.g., performance log entry 322 and memory access log entry 324) to a backup repository. In some examples, this operation occurs when a new entry is to be placed in the log and there is insufficient space for such entries, or when triggered by any technically feasible event, such as periodically. One or more log data consumers 310 may process information from performance log 306 and access log 308 in those logs or after such information has been written to the backup repository. In various examples, performance log 306 and access log 308 are stored in dedicated memory for logger 202, or in more general-purpose memory shared with other units (such as the general-purpose memory of APD 116). The backup repository acts as a larger overall memory for log entries, thus providing storage for such entries even when there is no more capacity for performance log 308 and access log 308.

[0043] The various functional units illustrated in the accompanying drawings and / or described herein (including, but not limited to, processor 102, auxiliary device 106, auxiliary processor 114, APD 116, I / O device 117, scheduler 136, computing unit 132, SIMD unit 138, recorder 202, client 302, memory 304, and log data consumer 310) may be implemented as a general-purpose computer, processor, processor core, or fixed-function circuit, or as a program, software, or firmware stored on a non-transitory computer-readable medium or other medium executable by a general-purpose computer, processor, or processor core, or as a combination of software executable on a processor or fixed-function circuit. The provided methods may be implemented in a general-purpose computer, processor, or processor core. For example, suitable processors include general-purpose processors, special-purpose 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 arrays (FPGAs), any other type of integrated circuit (IC), and / or state machines. Such processors can be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data, including netlists (such instructions capable of being stored on a computer-readable medium). The result of such processing can be a mask, which is then used in a semiconductor manufacturing process to manufacture a processor implementing the features of this disclosure.

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

Claims

1. A method, the method comprising: Multiple performance log entries are generated based on the observed operations; as well as Multiple memory access log entries are generated based on the observed operations. Each of the plurality of performance log entries is associated with one or more memory access log entries. Each performance log entry is associated with a period; as well as Each memory access log entry is associated with a period and a memory address range.

2. The method according to claim 1, wherein, Each performance log entry includes a set of performance statistics.

3. The method according to claim 2, wherein, The set of performance statistics includes information about the amount of data read from or written to the memory during a period.

4. The method according to claim 2, wherein, The set of performance statistics includes information about the bandwidth utilization of memory or data structures during a period.

5. The method according to claim 1, wherein, For a performance log entry associated with a period, the performance log entry includes one or more pointers to one or more memory access log entries for that period.

6. The method of claim 1, further comprising multiple memory access log entries among the multiple performance log entries being processed in parallel by multiple computing unit execution items.

7. The method according to claim 6, wherein, Parallel processing of the multiple memory access logs includes analyzing the multiple memory access logs to identify operational changes, thereby improving performance.

8. The method according to claim 1, wherein, Each memory access log entry includes memory accesses for the memory address range and statistics for the period associated with the memory access log entry.

9. The method of claim 1, further comprising storing each memory access log entry and each performance log entry in a backup repository.

10. A system comprising: Computing systems; and A recorder, the recorder being configured to: Multiple performance log entries are generated based on the observed operations; as well as Multiple memory access log entries were generated based on the observed operations. Each of the plurality of performance log entries includes one or more memory access log entries associated with it. Each performance log entry is associated with a period; and Each memory access log entry is associated with a period and a memory address range.

11. The system according to claim 10, wherein, Each performance log entry includes a set of performance statistics.

12. The system according to claim 11, wherein, The set of performance statistics includes information about the amount of data read from or written to the memory during a period.

13. The system according to claim 11, wherein, The set of performance statistics includes information about the bandwidth utilization of memory or data structures during a period.

14. The system according to claim 10, wherein, For a performance log entry associated with a period, the performance log entry includes one or more pointers to one or more memory access log entries for that period.

15. The system of claim 10, the method further comprising a processor configured to execute a plurality of computing unit execution items, the plurality of computing unit execution items being configured to process a plurality of memory access log entries among the plurality of performance log entries in parallel.

16. The system according to claim 15, wherein, Parallel processing of the multiple memory access logs includes analyzing the multiple memory access logs to identify operational changes, thereby improving performance.

17. The system according to claim 10, wherein, Each memory access log entry includes memory accesses for the memory address range and statistics for the period associated with the memory access log entry.

18. The system according to claim 10, wherein, The logger is further configured to store each memory access log entry and each performance log entry in a backup repository.

19. A non-transitory computer-readable medium for storing information, wherein the instructions, when executed by a processor, cause the processor to perform operations, the operations including: Multiple performance log entries are generated based on the observed operations; as well as Multiple memory access log entries are generated based on the observed operations. Each of the plurality of performance log entries is associated with one or more memory access log entries. Each performance log entry is associated with a period; and Each memory access log entry is associated with a period and a memory address range.

20. The system according to claim 19, wherein, The operation further includes storing each memory access log entry and each performance log entry into a backup repository.

Images