Adaptive prefetch activation in processors

Abstract

Implementations are disclosed for adaptively controlling a prefetch module by activating and deactivating the prefetch module. Prefetch operations are performed by the prefetch module to prefetch data from a data source to a cache of a processor based on a detected access pattern. Based on a performance metric associated with the prefetch operations, an occurrence of a first condition is detected, and the prefetch module is deactivated based on the occurrence of the first condition. After deactivating the prefetch module, an occurrence of a second condition is detected, and the prefetch module is reactivated based on the occurrence of the second condition. Adaptive activation and deactivation of the prefetch module in this manner can improve processor efficiency and help conserve power and system resources when prefetching would otherwise be determined to be inefficient, redundant, or non-productive.

Description

Background Technology

[0001] Modern processors, such as the Central Processing Unit (CPU), are designed to execute instructions at high speed. However, the speed and performance of these processors can be limited by the latency associated with fetching data from system memory. To mitigate this data access latency, processors typically incorporate cache memory with one or more levels. When the data requested by the processor core is in the cache (“cache hit”), the data can be retrieved quickly. However, if the data is not in the cache (“cache miss”), the processor must fetch the data from system memory, which can cause processor stalls and thus degrade overall processor performance. To reduce the frequency of cache misses, some processors employ prefetching techniques. For example, a prefetching unit can analyze memory access patterns to predict what data the processor is likely to need in the future. Therefore, in addition to fetching data when explicitly requested, processors with prefetching capabilities can also speculatively move data into the cache before it is actually needed. Summary of the Invention

[0002] Modern processors utilize data prefetching to anticipate future data needs and move data into the cache before it is explicitly requested, thereby reducing memory access latency. However, aggressive prefetching, especially in processors with large caches or multiple prefetching mechanisms, can lead to redundancy. Redundant prefetching occurs when speculatively fetching data that already exists in the cache or is otherwise unnecessary, consuming power and consuming valuable system resources without providing corresponding performance benefits. To address this inefficiency, the implementation described in this paper provides adaptive activation and deactivation of the prefetching module. For example, the control unit can monitor one or more performance metrics associated with prefetching operations. When these metrics indicate that prefetching is inefficient, inaccurate, or otherwise unproductive, the control unit can deactivate the prefetching module to save power and resources. The control unit can later reactivate the prefetching module, for example, after a set period of time or in response to changes in processor demand that indicate prefetching will be beneficial again. This dynamic control allows the system to realize the performance advantages of prefetching without sacrificing power and resource efficiency.

[0003] In some aspects, the technology described herein relates to a method comprising: performing a prefetch operation by a prefetch module of a processor to prefetch data from a data source to a cache of the processor, the prefetch operation being based on an access pattern detected by the prefetch module; detecting the occurrence of a first condition based on a performance metric associated with the prefetch operation; deactivating the prefetch module based on the occurrence of the first condition; detecting the occurrence of a second condition after the deactivation of the prefetch module; and reactivating the prefetch module based on the occurrence of the second condition.

[0004] In some aspects, the technology described herein relates to a processor comprising: a cache configured to receive data from a data source; a prefetch module configured to perform a prefetch operation to prefetch data from the data source into the cache, the prefetch operation being based on an access pattern detected by the prefetch module; and a control unit communicatively coupled to the cache and the prefetch module, the control unit being configured to: detect the occurrence of a first condition based on a performance metric associated with the prefetch operation; deactivate the prefetch module based on the occurrence of the first condition; detect the occurrence of a second condition after the deactivation of the prefetch module; and reactivate the prefetch module based on the occurrence of the second condition.

[0005] In some aspects, the technology described herein relates to a control unit for a processor having a prefetch module and a cache, the control unit including logic configured to: detect the occurrence of a first condition based on a performance metric associated with a prefetch operation, wherein the prefetch module prefetches data from a data source into a cache via the prefetch operation; deactivate the prefetch module in response to detecting the occurrence of the first condition; detect the occurrence of a second condition after deactivating the prefetch module; and reactivate the prefetch module in response to detecting the occurrence of the second condition.

[0006] Implementations may perform similar functions as described herein and / or may use other types of hardware to perform such functions. Specific implementations may involve systems, devices, media, and / or combinations thereof. Details of these and other implementations are set forth in the accompanying drawings and the following description. Other features will also become apparent from the following description, drawings, and claims. Attached Figure Description

[0007] Figure 1 An illustrative implementation of a control unit configured to perform adaptive prefetch activation in a processor, based on the principles described herein, is shown.

[0008] Figure 2 An illustrative element of a multi-core processor configured to perform adaptive prefetch activation is shown, based on the principles described herein.

[0009] Figure 3A An illustrative block diagram is shown regarding an adaptive prefetch activation implementation of the prefetch module for obtaining data for local caching, based on the principles described herein.

[0010] Figure 3B An illustrative block diagram is shown regarding an adaptive prefetch activation implementation of the prefetch module to obtain data for the shared cache, based on the principles described herein.

[0011] Figure 3CAn illustrative block diagram is shown regarding an adaptive prefetch activation implementation of a prefetch module targeting system memory to obtain data for a shared cache, based on the principles described herein.

[0012] Figure 4 An example prefetching unit comprising multiple prefetching modules is shown, based on the principles described herein.

[0013] Figure 5 Illustrative aspects of the conditions that can trigger adaptive prefetch activation and deactivation according to the principles described herein are shown.

[0014] Figure 6 An illustrative performance metric for adaptive prefetch activation in a processor is shown, based on the principles described herein.

[0015] Figure 7 An illustrative method for adaptive prefetch activation in a processor, based on the principles described herein, is shown.

[0016] Figure 8 A block diagram of an example computing system that can be incorporated with a processor that implements adaptive prefetch activation, based on the principles described herein, is shown. Detailed Implementation

[0017] The implementation described in this paper adaptively controls whether a prefetch module is activated or deactivated based on performance metrics and other conditions. Prefetching can improve processor performance by speculatively fetching data into a cache before it is formally requested, thereby reducing data access latency. However, under certain conditions, such as when a program's data occupancy space is in the cache, or when multiple prefetching mechanisms are active, prefetching can become redundant or inefficient, consuming power and system resources without corresponding performance benefits. To address this issue, the implementation described in this paper monitors the effectiveness of prefetching operations and dynamically deactivates the prefetch module when it is determined to be inefficient. The module can then be reactivated later, for example, after a specified period of time, or when system conditions indicate that prefetching will be beneficial again. In this way, performance gains from prefetching can be achieved without sacrificing power and resources in the processor.

[0018] To maximize instruction throughput, modern processors (Central Processing Unit (CPU), Graphics Processing Unit (GPU), etc.) attempt to process instructions as quickly as possible. To this end, for example, a processor may include multiple cores, each capable of executing instructions simultaneously in parallel. However, processor performance can be significantly limited by memory access latency, as fetching data from system memory can be much slower than the processor's execution speed. To compensate for this performance gap, processors can use cache memory to store frequently accessed data closer to the processing cores. When the requested data is found in the cache (“cache hit”), the cache can significantly reduce data retrieval time, thereby improving overall processor performance and instruction throughput.

[0019] In multi-core processor architectures, caching systems can be organized into hierarchical structures to efficiently manage data access across different cores. This hierarchy typically includes both local and shared caches. For example, each individual core can have its own dedicated high-speed local cache (e.g., a Level 1 (L1) cache), which can be directly integrated with the core (e.g., within the core's load-memory unit (LSU)) and configured to serve its immediate data needs. In addition to these local caches, multi-core processors can also incorporate shared caches with one or more levels (e.g., Level 2 (L2) cache, Level 3 (L3) cache, etc.). These shared caches can be accessible to multiple cores, providing a larger pool of shared memory that can be used to store data shared between different processing threads or to hold data that is accessed less frequently than data stored in the L1 cache.

[0020] Conventionally, data is cached based on explicit requests from the core for data that have been determined to be needed to execute specific instructions. Such requests can be referred to as "demand" requests. However, to further improve cache effectiveness, the processor can also employ a technique called "prefetching," in which data is predicted and speculatively fetched into the cache before the demand request explicitly requests it. For example, by analyzing memory access patterns, the prefetch unit can predict future data demands and proactively load that data, thereby increasing the likelihood of cache hits and minimizing processor pauses.

[0021] While prefetching can provide significant performance gains, it also introduces a number of technical problems, especially as processor architectures evolve with larger caches and more complex prefetching mechanisms. One such problem involves the increasing occurrence of redundant prefetching. This can occur when a prefetching module issues a request for a block of data that already exists in the cache (e.g., a cache line, data page, requested memory object, etc.) because that block has been requested by a previous request or introduced by another prefetching module (also called a “prefetcher”). Such redundant prefetching is inefficient and can consume valuable system resources such as processing loops (used for prefetch generation), queue occupancy (in request trace structures such as the Miss Status Disposal Register (MSHR)), Translation Back Buffer (TLB) lookups, and cache lookups, all without providing any corresponding performance benefit. This problem is particularly severe in scenarios involving programs with small data footprints that are entirely contained within the cache, where any prefetching activity will inherently be redundant and unhelpful.

[0022] Another technical challenge stems from the interaction between multiple prefetch modules included within a single prefetch unit, used to prefetch data for a single cache. A prefetch unit can include multiple prefetch modules, each designed to identify different types of access patterns. For example, one prefetch module might be configured to identify sequential or step-by-step memory access patterns, while another is configured to identify spatial access patterns by prefetching adjacent data blocks. As another example, one prefetch module could be a temporal prefetcher that re-fetches the most recently used data block, while another could be a streaming prefetcher that predicts and fetches the next data block in a sequential access pattern. Regardless of what access patterns each of these modules is configured to identify, the overall coverage or effectiveness of the prefetch unit can be affected by what the various prefetchers are configured to identify and what they aim to identify.

[0023] Therefore, while multi-module prefetching units can improve overall prefetch coverage, they can also introduce the technical problem of overlapping predictions by different prefetchers, leading to redundant requests for the same data. As an example, one prefetcher might issue a request for the same data only slightly later than a request from another prefetcher. In this case, the second prefetch is not only redundant but also late and provides no value. Besides the resource waste mentioned above, this technical problem of prefetch redundancy can also waste power, a significant issue for both battery-powered devices and large-scale data centers. Redundant prefetching can also lead to contention for memory bandwidth, potentially impacting the performance of non-speculatory memory accesses. Therefore, it is desirable for processors to dynamically manage prefetching activity to avoid such inefficiencies and resource waste.

[0024] Conventional solutions primarily focus on improving prefetch accuracy or adjusting activism, rather than directly addressing the technical issues of prefetch redundancy (e.g., by dynamically activating and deactivating prefetch mechanisms, as described in this paper). For example, some conventional approaches involve designing more complex prefetch units that can better predict future data demands. Other conventional solutions focus on having larger caches to reduce cache misses. However, these conventional solutions not only tend to fail to address the aforementioned technical problems but also often exacerbate them, as the redundancy issues only become more complex as the cache grows and the number of prefetchers increases. Furthermore, conventional approaches typically fail to consider the fact that even highly accurate prefetch units can become unnecessary or inefficient under certain conditions. For example, they do not consider scenarios where the program's working set is entirely within the cache, or scenarios where multiple prefetch modules are generating consistently overlapping requests. Therefore, these conventional solutions fail to provide an adaptive mechanism that balances the performance benefits of prefetching with power savings and other valuable system resources.

[0025] To address these technical challenges, the implementation described in this paper provides various technical solutions involving adaptive prefetch activation mechanisms. As will be detailed below, these solutions can involve dynamically activating and deactivating the prefetch module based on real-time performance metrics that indicate whether the prefetch operation is efficient and beneficial. In this way, processor runtime can be divided into sampling periods or phases (during which prefetching is active and its effectiveness is monitored) and deactivation (or shutdown) periods or phases (during which the prefetch module is shut down to conserve power and resources). The duration of these phases can be adaptively adjusted based on the results collected during the sampling periods.

[0026] Some of the technical solutions described herein involve monitoring performance metrics related to demand requests from processor cores. For example, the control unit can track the ratio of demand requests hitting data introduced by previous demand requests in the cache. If this ratio is high, it indicates that the program's working set (i.e., the data accessed by the program during execution) may be entirely in the cache, making any prefetching redundant. If this is detected, the technical solutions described herein will cause the prefetch module to be deactivated at least temporarily to conserve power and other resources. As another example, the performance of the prefetch module itself can be monitored. For example, the control unit can measure the prefetch "drop rate" (i.e., the ratio of prefetch request target data already present in the cache or in the request trace structure (e.g., MSHR) due to previous requests from another prefetcher). A high drop rate may indicate that the prefetch module is redundant or arrives late. Therefore, the technical solutions described herein can provide deactivation of a particular prefetch module in response to detected inefficiency. These technical solutions can be combined, for example, by deactivating prefetching if a demand-based or prefetch-based metric exceeds a certain threshold.

[0027] To re-initiate prefetching after a deactivation period, the technical solutions described herein provide several methods. For example, the prefetch module can be reactivated after a predetermined deactivation period expires. The duration of this period can be adaptively adjusted based on a "stop confidence" metric, which can be updated over time based on continuous sampling results. For example, if sampling repeatedly indicates high redundancy, the deactivation period can be extended, while if sampling indicates low redundancy, the deactivation period can be shortened. As another example, reactivation can be triggered by a change in a demand-related performance metric (which can be monitored even when the prefetch module is inactive during the deactivation phase), such as a change in a demand request that would indicate prefetching will be beneficial again.

[0028] The implementation described in this paper can provide several advantageous technical effects. For example, one technical effect involves a significant reduction in power consumption by deactivating the prefetch module when its operation is determined to be redundant or unnecessary. By avoiding wasted prefetch requests, this technical effect leads to cooler processors and improved battery life in mobile devices. Another significant technical effect involves more efficient utilization of system resources. By preventing redundant prefetching, valuable resources such as memory bandwidth, MSHR entries, and TLB lookup capacity can be freed up for other more useful operations. This technical effect can lead to an overall improvement in system performance because contention for these resources is reduced.

[0029] Furthermore, the adaptive nature of this mechanism provides a technical effect that makes data prefetching more efficient and effective overall. By dynamically turning prefetching modules and / or entire prefetching units on and off based on their actual performance contribution, the system ensures that prefetching only operates when it is truly beneficial. This targeted approach minimizes the negative performance impact that could result from unnecessary prefetch generation and queue occupancy. This technical effect ensures that the processor can realize the performance advantages of prefetching without the associated costs of inefficiency and resource waste. Overall, these technical effects result in smarter and more energy-efficient processor designs that can adapt to a wide range of workloads and operating conditions.

[0030] Some terms used in this specification may be understood in the following sense to help describe the principles set forth herein. These definitions are provided by way of example and are not intended to be restrictive; they may be added to and / or further defined and clarified by the examples described herein.

[0031] As used herein, a prefetch module can refer to a hardware logic unit or a combination of hardware and software configured to predict future data needs of the processor core by analyzing memory access patterns and speculatively issue prefetch requests for that data. As described herein, multiple prefetch modules (or “prefetchers”) may be included in a single prefetch unit. Prefetch operation can refer to the entire process by which a prefetch module performs its prefetch task, including monitoring access patterns, generating prefetch requests, and interacting with caches and data sources to speculatively move data (e.g., functional operations of the prefetch module and / or prefetch unit). A cache can refer to a high-speed memory component, such as a local cache (e.g., L1 cache) or a shared cache, configured to store data closer to the processor core to reduce access latency. A data source can refer to any level of the memory hierarchy from which the prefetch module can extract data, such as higher-level caches (e.g., shared L2 or L3 caches) or system memory.

[0032] As used herein, an access pattern can refer to a discernible sequence or regularity in memory access requests that the prefetch module can detect to predict future data needs, such as sequential, step-by-step, or spatial access patterns. A performance metric can refer to a quantifiable measure of processor or prefetcher activity used to evaluate the efficiency or effectiveness of prefetch operations, such as prefetch drop rate, prefetch accuracy, demand miss rate, or cache hit rate. A condition (and the occurrence of a condition) can refer to a specific state or event that can be detected and trigger a change in the operational state of the prefetch module (e.g., a performance metric exceeding a threshold, a timer expiring, etc.). The terms deactivation, activation, and reactivation can refer to the processes of disabling, enabling, and re-enabling the functionality of the prefetch module to control its power consumption and resource utilization, respectively. A demand request can refer to an explicit, non-speculsive memory access request initiated by the processor core for data required to execute a specific instruction. In contrast, a prefetch request can refer to a speculative memory access request initiated by the prefetch module to proactively fetch data into the cache before a demand request explicitly requests data.

[0033] Various implementations will now be described in more detail with reference to the accompanying drawings. It should be understood that the specific implementations described below are provided only as non-limiting examples and are applicable to a variety of situations. Furthermore, it should be understood that other implementations not explicitly described herein may also fall within the scope of the claims set forth below. The systems and methods described herein for adaptively activating and deactivating prefetch modules can produce any or all of the technical effects mentioned above, as well as various additional effects and benefits that will be described below and / or become apparent.

[0034] Figure 1 An illustrative implementation 100 of a control unit 102 configured to perform adaptive prefetch activation in a processor, based on the principles described herein, is shown. More specifically, implementation 100 shows that control unit 102 can be configured to analyze certain demand-based performance metrics 104 and / or prefetch-based performance metrics 106 to generate a prefetch activation output 108 configured to control whether the prefetch module is activated (i.e., enabled and configured to prefetch memory data for caching) or deactivated (i.e., disabled and configured to avoid prefetching). For example, as Figure 1 As shown in the exploded view 110 of the prefetch activation output 108, the prefetch activation output 108 can cause the prefetch module to swing back and forth between an on state ("activated") and a off state ("deactivated") within a time period represented by a time line (labeled "time"). In the on state, the prefetch module is enabled and active, and in the off state, the prefetch module is disabled and inactive.

[0035] The transition from an activated state to a deactivated state is shown as being triggered by the occurrence of certain conditions in the system. For example, the occurrence of the first condition 112-1 is shown as triggering the transition of the prefetch module from an activated state to a deactivated state, while the occurrence of the second condition 112-2 is shown as triggering the transition of the prefetch module from a deactivated state back to an activated state. This will now be described in more detail. Figure 1 Each of the elements shown.

[0036] Control unit 102, which may be implemented by a combination of hardware logic and / or software, is configured to monitor processor performance and dynamically control the activation state of prefetch modules (not explicitly shown in the example of implementation 100). For example, control unit 102 may be a dedicated logic block within the processor, an executable instruction set running on the processor core, etc. As shown, control unit 102 may receive one or more performance metrics (or information from which these metrics can be derived), such as demand-based metric 104 and prefetch-based metric 106. Control unit 102 may analyze these metrics to evaluate the current value of prefetch operations performed by one or more prefetch modules in the processor's prefetch units (i.e., to determine whether prefetching is beneficial or redundant, etc.). Based on this analysis, control unit 102 is shown generating a prefetch activation output 108, which may be a signal or command to activate or deactivate a target prefetch module or prefetch unit.

[0037] Demand-based performance metrics 104 refer to information related to the performance and behavior of non-speculatory memory requests initiated by the processor core. These metrics can provide insights into whether prefetching is necessary. For example, a high ratio of demand requests that hit data introduced by previous demand requests in the cache can indicate that the program's working set is in the cache, suggesting that prefetching is redundant. Other examples of demand-based metrics may include overall demand miss rate or miss latency. Control unit 102 may monitor these metrics, for example, by receiving data from a performance monitoring unit (PMU) counter associated with a data source (e.g., a higher-level cache targeted by the prefetch module), to make informed decisions about prefetch activation.

[0038] Similarly, prefetch-based performance metrics 106 refer to information related to the effectiveness and efficiency of the prefetching operations of one or more prefetching modules within a prefetching unit. These metrics can help determine whether a particular prefetching module is operating redundantly or inaccurately. For example, a prefetch “drop rate” metric can track the frequency with which prefetch requests target blocks of data that are already in the cache or in a request tracking structure (e.g., a miss status disposition register (MSHR)) due to previous requests from another prefetching module. A high drop rate can indicate that a prefetching module is late or that its predictions overlap with those of other prefetching modules. Other metrics in this category may include prefetch accuracy (the frequency with which prefetched data is used) and prefetch coverage (how many request misses are prevented by prefetching). Similar to demand-based metrics 104, control unit 102 can use these prefetch-based metrics 106 to selectively deactivate poorly performing or redundant prefetching modules.

[0039] Prefetch activation output 108 represents a control signal, a command generated by control unit 102, or other control mechanism by which control unit 102 manages the operating state of a specific prefetch module within the prefetch unit. For example, this output can be implemented as a binary signal (e.g., high for activation, low for deactivation), a control register setting, or another suitable mechanism. As shown in the timeline of exploded Figure 110, prefetch activation output 108 can dynamically transition the prefetch module between an "activated" (on) state and a "deactivated" (off) state, in which the prefetch module actively performs prefetching, and in the "deactivated" (off) state, the prefetch module idles to conserve power and resources. Prefetch activation output 108 can be generated based on one or more performance metrics (e.g., any suitable metric or a combination of demand-based metric 104 and / or prefetch-based metric 106) and other conditions (such as time-based conditions described in more detail below). Dynamic control of this output can help allow the system to balance the performance gains of prefetching with the need for efficiency.

[0040] Exploded Figure 110 illustrates the dynamic, time-varying nature of the prefetch activation control. The horizontal axis represents time, during which the state of the prefetch module alternates between an activated phase and a deactivated phase. The activated phase can correspond to a “sampling” phase, in which the prefetch module operates and its performance is monitored by the control unit 102. The deactivated phase can correspond to a “stop” phase, in which prefetching is shut down in response to the detection of inefficiency or redundancy. The duration of these phases can be adaptively adjusted based on performance metrics collected during the sampling phase, thereby achieving a flexible duty cycle that balances performance and power savings.

[0041] The first condition 112-1 represents a trigger for deactivating the prefetch module. The control unit 102 can detect the occurrence of this condition when one or more performance metrics (e.g., demand-based metric 104 and / or prefetch-based metric 106) exceed a predetermined threshold, indicating that prefetching has become inefficient, redundant, or inaccurate. For example, the first condition 112-1 may occur if the prefetch drop rate exceeds a certain percentage, or if the demand hit rate for previously on-demand loaded data is very high. In some implementations, the first condition 112-1 can be triggered if either the demand-based metric or the prefetch-based metric indicates inefficiency, thereby allowing for more aggressive deactivation.

[0042] The second condition 112-2 represents a trigger used to reactivate the prefetch module after a deactivation period. The occurrence of this condition can be detected based on several factors. In one example, the second condition 112-2 may occur after a predetermined deactivation period has expired (based on a timing condition). The duration of this period can be adaptively adjusted based on a "stop confidence" metric, which can be updated based on continuous sampling results. In another example, the second condition 112-2 may be detected in response to a change in a demand-based performance metric (such as an increase in demand miss rate), indicating that prefetching may be beneficial again. In some implementations, the occurrence of the second condition 112-2 may require both the expiration of the deactivation period and the crossing of a demand-based metric threshold.

[0043] Implementation 100 is provided as an illustrative example of how adaptive prefetch activation can be configured. It should be understood that other implementations may include more or fewer elements and may be arranged differently. For example, some implementations may rely solely on demand-based metrics, while others may incorporate both prefetch-based and core performance metrics with a wider range. The specific thresholds and logic used to detect the first and second conditions may also vary (examples of which are provided below). Various other aspects of this and other implementations will now be described in more detail with reference to the accompanying drawings.

[0044] Figure 2 Illustrative elements of a multi-core processor configured to perform adaptive prefetch activation, based on the principles described herein, are shown. More specifically, Figure 2A processor 200 is depicted, in which it can be implemented as a multi-core central processing unit (CPU). The processor 200 is shown as including multiple cores 202 (each core including its own local cache 204), a shared cache 206, possible additional caches 208, and a memory controller 210 communicating with system memory 212, shown as being external to the processor 200. Each of the local cache 204, shared cache 206, and additional cache 208 is shown as being incorporated into a request trace structure 214. This architecture provides a hierarchical memory system in which data can be efficiently managed and accessed by the cores, wherein a prefetch mechanism operates between different levels of the hierarchy, as will be described in further detail below. Each of these components will now be described in more detail.

[0045] Processor 200 may be a central processing unit (CPU), a graphics processing unit (GPU), or another suitable type of processor. In this particular example, for instance, processor 200 is shown as being implemented as a multi-core CPU. Processor 200 is configured to execute instructions by fetching data from a memory hierarchy that includes system memory 212 and one or more levels of cache, such as local cache 204, shared cache 206, and (in some implementations) one or more levels of additional cache 208. To improve performance, processor 200 may employ a prefetching technique that can be adaptively managed as described herein.

[0046] Each core 202 represents an individual processing unit within the multi-core processor 200. Cores 202 can be configured to execute their own corresponding instruction stream, thereby generating demand requests for data blocks referenced by the instructions they are executing. For example, a core 202 can access system memory 212 through its local cache 204 and shared caches at various levels, as well as a controller between that core and system memory 212. As shown, the processor 200 includes multiple cores 202 (two are shown, but the ellipsis will be understood as indicating that they are not in use). Figure 2 (Potential additional cores are explicitly shown in the diagram), thereby allowing parallel processing of multiple threads or applications. Each core 202 can have its own dedicated resources, such as registers and execution units, and can share other resources with other cores, such as shared cache 206.

[0047] The local cache 204 of core 202 will be understood as a cache memory dedicated to serving the specific cores it serves. For example, local cache 204 can be implemented as a Level 1 (L1) cache, whose proximity to the core allows for very low-latency data access for the immediate data needs of that core. As mentioned above, data can be non-speculated based on demand requests from core 202 and / or via a prefetch module ( Figure 2 Prefetch requests (not explicitly shown, but understood to be integrated at various levels of the memory hierarchy, as further described below) are speculatively moved to caches (such as local cache 204). In some implementations, a prefetch module (e.g., included within a prefetch unit along with one or more other prefetch modules) can prefetch data from a data source, such as shared cache 206, into local cache 204.

[0048] As shown, shared cache 206 can be used as a cache memory level accessible to multiple cores 202. For example, shared cache 206 can be implemented as a Level 2 (L2) cache. Shared cache 206 provides a larger common memory pool that can store data shared between different processing threads and / or hold data that is accessed less frequently compared to data stored in local cache 204. As shown, shared cache 206 can be communicatively coupled to local caches 204 of multiple cores 202. In some implementations, shared cache 206 can receive prefetched data. For example, a prefetch module can prefetch data into shared cache 206 from a data source such as system memory 212 or additional cache 208 (if present). In other implementations, shared cache 206 can serve as a data source from which data is prefetched into various local caches 204 of core 202, for example. The shared nature of this cache makes it a central point for monitoring memory access patterns across multiple cores, which can influence prefetch decisions.

[0049] Additional cache 208 can represent one or more additional levels in the cache hierarchy, such as a Level 3 (L3) cache or another suitable last-level cache (LLC). Such a cache can provide even greater capacity for storing data and can be shared among all cores 202. Similar to shared cache 206, additional cache 208 can be used as a cache to receive prefetched data or as a data source for prefetch operations targeting higher-level caches. For example, in one implementation, shared cache 206 can implement a cache for prefetch operations, while additional cache 208 implements a data source.

[0050] Memory controller 210 represents a hardware unit that can manage the data flow between processor 200 and system memory 212. Therefore, it can receive memory requests from cache hierarchies (e.g., from the last-level cache, such as shared cache 206 or additional cache 208) and translate them into appropriate signals for accessing system memory 212. Although included in processor 200 in this example, it should be understood that in some examples, memory controller 210 may be located off-chip. It should be understood that memory controller 210 can be configured to act as an intermediary rather than the data source itself. For example, memory controller 210 can facilitate communication between caches such as additional cache 208 or shared cache 206 and data sources such as system memory 212. In such cases, although requests may be sent to memory controller 210, the data is ultimately retrieved from system memory 212.

[0051] System memory 212 may represent the main memory used by processor 200. This memory can be implemented using any suitable technology or storage medium. For example, system memory 212 may be implemented using dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, solid-state drive (SSD), or another suitable storage medium. In this implementation, system memory 212 may represent the final data source for the memory hierarchy. In some implementations, prefetching operations may target system memory 212 to feed data into one of the caches, such as shared cache 206 or additional cache 208.

[0052] Request trace structure 214 will be understood as representing a hardware component, such as a Miss Status Disposal Register (MSHR) or other such structures configured to track incomplete memory requests that have missed in a particular cache. When a cache miss occurs (whether for a demand request or a prefetch request), an entry can be allocated in a specific request trace structure 214 to manage the miss state until the requested data is retrieved from the next level of the memory hierarchy. This structure prevents redundant requests for the same data block by tracking pending requests. In the context of adaptive prefetching described herein, these structures can be particularly useful for detecting redundant prefetching. For example, as will be further described below, if a prefetch module issues a prefetch request for a data block that already has a pending request from another prefetch module, the request will hit in request trace structure 214. This hit can be incorporated into a performance metric that indicates prefetch inefficiency, as will be further described below.

[0053] Figure 3A , Figure 3B and Figure 3CIllustrative block diagrams are shown for several implementations of adaptive prefetch activation. Figure 3A In the block diagram of implementation 300-A, the prefetch module obtains data for local caching. Figure 3B In the block diagram of implementation 300-B, the prefetch module obtains data for the shared cache. Figure 3C In the block diagram of implementation 300-C, the prefetch module targets system memory to obtain data for shared cache. These diagrams illustrate... Figure 2 The different prefetch scenarios within the processor architecture demonstrate the flexibility of the adaptive activation mechanism.

[0054] Figure 3A , Figure 3B and Figure 3C The implementations shown share several common elements and interactions. In each diagram, the prefetch module 302 is configured to perform a prefetch operation by analyzing memory access patterns to predict future data needs. The control unit 304 is communicatively coupled to the prefetch module 302 and is configured to monitor the performance of its prefetch operation and adaptively activate or deactivate the prefetch module 302. Although for clarity... Figures 3A to 3C Only a single prefetch module 302 is shown in this document, but it should be understood that a prefetch unit may include multiple such modules, each potentially configured to detect different types of access patterns. As further described herein, the presence of multiple prefetch modules can introduce complex interactions because their predictions may overlap, resulting in redundant prefetch requests. The adaptive activation mechanism described herein can be applied to individual prefetch modules to selectively deactivate those prefetch modules identified as redundant or inefficient, as will be described in more detail below.

[0055] Each diagram illustrates two main types of memory access requests to a data source. Demand request 306 represents (e.g., in response to a request from core 202) an explicit, non-speculsive request for data initiated by the cache. In contrast, prefetch request 308 represents a speculative request initiated by prefetch module 302 to proactively fetch data into the cache before it is formally needed. The effectiveness and efficiency of these requests can be monitored using, for example, one or more counters 310 associated with the data source. These counters 310 can be implemented, for example, by a performance monitoring unit (PMU) counter configured to track various events, such as cache hits and misses for both demand request 306 and prefetch request 308. Counters 310 provide performance metric data 312 to control unit 304, which analyzes the data to evaluate the efficiency and accuracy of the prefetch operation. For example, performance metric data 312 can indicate prefetch redundancy or inaccuracy, as already described.

[0056] In some implementations, performance metric data 312 may include any of the various performance metrics described herein that are directly provided to control unit 304. In other implementations, performance metric data 312 may include raw counter values ​​from counter 310, which control unit 304 can then use to determine or generate relevant performance metrics. This allows for flexible performance evaluation, whether through direct metric monitoring or indirect calculations based on event counts. Similarly, the prefetch activation / deactivation signal 314 sent by control unit 304 can be implemented in various ways. For example, in one implementation, signal 314 may be implemented using a single bit that is toggled on or off to enable or disable prefetch module 302. Alternatively, signal 314 may represent more complex signaling, such as a specific command instructing prefetch module 302 to enter an active or idle state, or a change to control register settings.

[0057] Based on its analysis of performance metric data 312, control unit 304 generates a prefetch activation / deactivation signal 314 to manage the operational state of prefetch module 302. For example, if prefetching is determined to be inefficient, control unit 304 can send a signal to deactivate prefetch module 302. Later, when a second condition occurs, control unit 304 can send another signal to reactivate prefetch module 302. Prefetch module 302 can then use training data 316, which can be provided by the cache it is currently serving, to identify access patterns and improve its prefetch predictions while the prefetch module is active. Training data 316 can be the recent memory access request flow observed by the prefetch module. For example, the prefetch module may observe sequential accesses to addresses A, A+1, and A+2, identify this as a pattern, and predict future needs for address A+3.

[0058] Figure 3A Implementation 300-A is shown, in which the prefetch module 302 prefetches data from the shared cache 206 for use in the local cache 204. In this configuration, the local cache 204 (e.g., the L1 cache of core 202) can be used as a “cache” to receive the prefetched data, while the shared cache 206 (e.g., the L2 cache) serves as a “data source” from which data is extracted. The prefetch module 302 analyzes the training data 316 from the local cache 204 to predict and prefetch blocks of data from the shared cache 206, aiming to reduce the latency of core 202.

[0059] Figure 3BImplementation 300-B is illustrated, in which the prefetch module 302 obtains data for the shared cache 206 from another level of cache (such as the additional cache 208). In this scenario, the shared cache 206 (e.g., an L2 cache) can be used as a “cache” for receiving the prefetched data, while the additional cache 208 (e.g., an L3 cache) serves as a “data source” from which data is extracted. Similar to what has been described above, the prefetch module 302 can be trained on access patterns observed at the shared cache 206 to proactively move data from the additional cache 208 to the shared cache 206.

[0060] Figure 3C Implementation 300-C is illustrated, in which the prefetch module 302 obtains data for the shared cache 206 by targeting the system memory 212 via the memory controller 210. In this configuration, the shared cache 206 (e.g., an L2 or L3 cache) can be used as a "cache," while the system memory 212 serves as a "data source." As shown (and as described above), a memory controller, such as the memory controller 210, can facilitate communication between the prefetch module 302 and the system memory 212. In this example, the counter 310 is managed by the memory controller. The prefetch module 302 analyzes access patterns from the shared cache 206 to prefetch data from the system memory 212, aiming to reduce latency associated with main memory access.

[0061] Figure 4 An example prefetch unit 400 comprising multiple prefetch modules (e.g., implementations of prefetch modules as described above, such as prefetch module 302) is shown, based on the principles described herein. As shown, prefetch unit 400 includes multiple prefetch modules, shown as prefetch modules 302-1, 302-2, 302-3 to 302-N. Each of these prefetch modules can be configured to identify and act upon different types of memory access patterns. For example, prefetch module 302-1 can detect a first access pattern (e.g., sequential pattern), prefetch module 302-2 can detect a second access pattern (e.g., strafing pattern), prefetch module 302-3 can detect a third access pattern (e.g., spatial pattern), and so on. Other examples of memory access patterns that different prefetch modules can be configured to identify include time patterns, stream-based patterns, and other suitable access patterns. By incorporating multiple prefetch modules—each targeting a different access pattern—prefetch unit 400 can achieve broader and more efficient prefetch coverage.

[0062] A control unit, such as control unit 304, can manage prefetching activities by controlling prefetching unit 400 in at least two main modes. A first mode involves globally deactivating the prefetching unit, where control unit 304 deactivates the entire prefetching unit 400. This can occur, for example, in response to a performance metric indicating that all prefetching activities are currently redundant, such as when the program's working set is entirely in the cache. A second mode involves selectively deactivating prefetching modules independently of other prefetching modules. In this mode, control unit 304 can deactivate individual prefetching modules (e.g., prefetching module 302-1) while allowing other prefetching modules (e.g., prefetching modules 302-2, 302-3 through 302-N) to remain active.

[0063] The principle behind this type of selective deactivation can be to address situations where a particular prefetch module becomes inefficient or redundant due to overlapping predictions with other modules. For example, prefetch module 302-1, configured to detect sequential mode, may issue a prefetch request that is also being issued by prefetch module 302-2, which may be a more complex streaming prefetcher. If performance metrics indicate that prefetch module 302-1 consistently generates late or redundant requests that have already been processed by prefetch module 302-2, the control unit can selectively deactivate only the underperforming prefetch module 302-1. This targeted deactivation allows the processor to save power and system resources without sacrificing the performance advantages provided by other still-functional prefetch modules.

[0064] Figure 5 An illustrative implementation 500 of logical conditions that can be used to trigger adaptive prefetch activation and deactivation is shown. More specifically, implementation 500 illustrates how a control unit (such as control unit 102 or 304) can use one or more conditions to transition the prefetch module between an active state (“activation period”) and an inactive state (“deactivation period”), as shown along a timeline. Therefore, Figure 5 This demonstrates an important aspect of the logical framework for dynamically managing the operational state of the prefetch module to balance performance with power and resource efficiency.

[0065] The transition from activation to deactivation is shown as being triggered by the occurrence of a first condition 502-1. In this example, this first condition can be configured to occur when prefetching is determined to be inefficient or redundant. As shown, in this example, the first condition 502-1 can be detected when either demand-based performance metric 504 or prefetch-based performance metric 506 exceeds a predetermined threshold. For example, demand-based performance metric 504 could be a high core hit rate on data introduced by a previous demand request, indicating that the program's working set is in the cache and does not require prefetching. As another example, prefetch-based performance metric 506 could be a high prefetch drop rate, indicating that a prefetch request is targeting data that is already in the cache or being fetched by another prefetcher. By using OR logic (e.g., represented by an OR gate in the diagram), the system can deactivate the prefetch module in response to an inefficient demand-side or prefetch-side indicator. Various other examples of both demand-side and prefetch-side performance metrics are described in more detail below.

[0066] The transition from the deactivation period back to the activation period can then be triggered by detecting the occurrence of the second condition 502-2. This condition can be configured to occur when prefetching is likely to be beneficial again. As shown, in this example, the second condition 502-2 can be detected when both of the following sub-conditions are met: 1) the deactivation period expires 508, and 2) an additional demand-based performance metric 504 meets (e.g., exceeds) a certain threshold. The deactivation period expires 508 to ensure that the prefetching module remains inactive for a minimum duration to conserve resources. Additional checks on the demand-based performance metric 504 (such as an increased demand miss rate) provide the indication that the program's behavior has changed and prefetching will be beneficial to performance again. For this condition, the use of AND logic (e.g., represented by an AND gate in the diagram) ensures that reactivation is both timely and guaranteed by system performance requirements.

[0067] It should be understood that any suitable single performance metric or factor, or any suitable logical combination of performance metrics or other factors (e.g., time-based factors such as timer expiration), can be used to trigger the transition between an active and deactivated period. For example, in some implementations, the first condition 502-1 can be triggered by a logical AND of a demand-based performance metric 504 and a prefetch-based performance metric 506. Similarly, although Figure 5 The AND gate used for the second condition 502-2 is depicted, but other implementations can trigger reactivation based on a demand-based performance metric 504 or the expiration of a deactivation period 508 (as indicated by the dashed arrows that bypass the AND gate for such implementations). This logical flexibility allows the system to be tailored for various performance objectives, such as more aggressive or more conservative activation and deactivation strategies.

[0068] By iteratively evaluating these types of conditions, the system can create dynamic operations that effectively and efficiently transition between activation and deactivation periods. The activation period can be used as a sampling phase, during which the effectiveness of prefetching is monitored. The deactivation period can be used as a stopping phase, during which the prefetching module is idle to conserve power and resources. This adaptive control allows the processor to intelligently balance the performance gains and efficiency requirements of prefetching, thereby responding in real time to changing workload characteristics.

[0069] Figure 6 A block diagram illustrating various categories of performance metrics that can be used by a control unit for adaptive prefetch activation is shown. More specifically, the diagram depicts a control unit 600 that uses various performance metrics 604 to make adaptive activation decisions. The control unit 600 is shown as including a timekeeping block 602. The timekeeping block 602 can be configured to manage the duration of different operational phases such as activation (or sampling) periods and deactivation (or stop) periods. For example, the timekeeping block 602 can use counters to define the length of these periods, and the timekeeping block can be adaptively adjusted based on the performance metrics 604 collected during sampling.

[0070] One category of performance metrics 604 is prefetch inefficiency metrics 606-1 to 606-3. These metrics correspond to inefficiencies in the prefetch operation, which may be conditions used to deactivate the prefetch module. In some implementations, these metrics can be determined by calculating a portion (such as a percentage) of the total number of events or by calculating the ratio of one type of event to another type of event (such as a hit to a miss). The resulting values ​​can then be compared to predetermined thresholds to detect whether an inefficiency condition has occurred.

[0071] In one example, inefficiency metric 606-1 can represent inefficiency in prefetching operations as a portion of a prefetch request performed by the prefetch module that hits a data block (also known as a cache line) introduced by a previous demand request in the cache. A high value for this metric may indicate that the program's working set is placed in the cache, making prefetching activity redundant. If this performance metric exceeds a predetermined threshold, the prefetch module can be deactivated.

[0072] In another example, for a processor where the prefetch module is a first prefetch module included in a prefetch unit having a second prefetch module, an inefficiency metric 606-2 can be used. This performance metric represents inefficiency in prefetch operation as a portion of a prefetch request performed by the first prefetch module that is cache-hit based on a previous prefetch request performed by the second prefetch module. A high value of this metric can indicate that the first prefetch module is generating late or overlapping requests. If the metric exceeds a predetermined threshold, it indicates that the operation of the first prefetch module is inefficient (e.g., redundant), and it can be a candidate for selective deactivation.

[0073] As yet another example, in the case where the prefetch module is again the first prefetch module in a prefetch unit with a second prefetch module, an inefficiency metric 606-3 can be used. This performance metric represents inefficiency in the prefetch operation as a portion of a prefetch request made by the first prefetch module that matches an pending prefetch request made by the second prefetch module within a request tracking structure (e.g., MSHR). A high value of this metric can also indicate that the prediction of the first prefetch module is late or overlaps with the predictions of other prefetchers, thus indicating inefficiency. If this portion exceeds a predetermined threshold, the first prefetch module can be deactivated.

[0074] Another category shown is prefetch inaccuracy metric 608. Prefetch inaccuracy metric 608 corresponds to inaccuracies in the prefetch operation. For example, these metrics can be used to measure the ratio of prefetched data actually consumed by the processor core before it is evicted from the cache. A low consumption rate (i.e., a high evict rate of unused prefetched data) can correspond to high inaccuracies in the prefetch operation. If this inaccuracy metric exceeds a predetermined threshold, the occurrence of a first condition can be detected, and the prefetch module can be deactivated.

[0075] Another category shown is core performance metric 610. Core performance metric 610 can be used to measure the hit rate of a processor core against its own demand requests during a prefetch operation. This hit rate can be used as an indicator of whether prefetching is currently beneficial. For example, if the core demand hit rate is very high, it may indicate that the program's working set is in the cache and prefetching may not be necessary. If this performance metric exceeds a predetermined threshold, the occurrence of a first condition can be detected, and the prefetch module can be deactivated.

[0076] Figure 7An illustrative method 700 for adaptive prefetch activation in a processor, based on the principles described herein, is illustrated. Method 700 can be performed by a processor or its components—such as a control unit (e.g., control unit 102, 304, or 600) configured to control the activation and deactivation of at least one prefetch module. Method 700 provides an illustrative set of operations for adaptive prefetch activation in a processor (e.g., processor 200). The operations of method 700 are illustrative and can be performed in different orders, and in various implementations, some operations may be optional or combined. For example, the method can be implemented as part of a loop that divides runtime into an active (or sampling) period in which prefetching is active and a deactivation period in which prefetch modules are inactive to save power and system resources.

[0077] At operation 702, the prefetch module (e.g., prefetch module 302) can perform a prefetch operation to prefetch data from a data source into a cache. For example, the prefetch module can perform the prefetch operation by detecting an access pattern and issuing a prefetch request to the data source based on the detected access pattern. In one example, the data source can be a shared cache (e.g., shared cache 206) and the cache can be a local cache (e.g., local cache 204), or in another example, the data source can be system memory (e.g., system memory 212) and the cache can be a shared cache. In any case, the prefetch operation can be performed when the prefetch module is activated (i.e., in an active, enabled, or sampling state as already described).

[0078] At operation 704, the control unit (e.g., control unit 304) can detect the occurrence of the first condition based on performance metrics associated with the prefetch operation. For example, the control unit can monitor one or more performance metrics (e.g., performance metric 604) to evaluate the effectiveness of the prefetch operation. The first condition can be detected when a performance metric exceeds a predetermined threshold. Performance metrics can be of several types, such as inefficiency metrics (e.g., prefetch inefficiency metrics 606-1 to 606-3), inaccuracy metrics (e.g., prefetch inaccuracy metric 608), core performance metrics (e.g., core performance metric 610), or another suitable metric. For example, an inefficiency metric can track the rate at which prefetch requests target data already present in the cache, while an inaccuracy metric can track the frequency with which prefetched data is not used.

[0079] At operation 706, the control unit can deactivate the prefetch module based on the occurrence of a first condition. For example, in response to detecting that the prefetch is inefficient, redundant, or inaccurate, the control unit can transition the prefetch module from an active state to a deactivated or inactive state. This deactivation helps save power and system resources, such as memory bandwidth and request tracking structure occupancy, by preventing the prefetch module from issuing further speculative requests that provide little or no performance benefit. Deactivation can be applied to a single prefetch module within a larger prefetch unit (e.g., prefetch unit 400) or to the entire prefetch unit.

[0080] At operation 708, the control unit can detect the occurrence of a second condition. This detection can occur in several ways. In one implementation, the second condition occurs when the deactivation period has expired. The duration of this deactivation period can be adaptively determined. For example, a "stop confidence" value can be used to adjust the duration of subsequent deactivation periods based on performance metrics collected during previous active phases. If sampling repeatedly indicates high redundancy, the deactivation period can be extended, while if sampling repeatedly indicates low redundancy, the deactivation period can be shortened to save power and resources. In another implementation, the second condition can be detected based on an additional performance metric (e.g., a demand-based metric, such as the core demand miss rate), which can be monitored even when the prefetch module is deactivated. An increase in this metric may indicate that program behavior has changed and prefetching will be beneficial again. In yet another implementation, as already described, the second condition can be detected based on both the expiration of the deactivation period and the detection of exceeding a demand-based threshold.

[0081] At operation 710, the control unit can reactivate the prefetch module based on the occurrence of the second condition. For example, upon detecting the second condition, the control unit can switch the prefetch module back to the active state, thereby allowing the prefetch module to resume its prefetch operation. This reactivation completes an adaptive cycle, enabling the system to dynamically and effectively balance prefetch advantages with power and system resource savings as the workload changes.

[0082] Figure 8This is a block diagram of an example computing system 800 that can implement or be used with the principles described herein. In some implementations, computing system 800 may be configured to perform adaptive prefetch activation in a processor (such as processor 200), or otherwise incorporated with one or more of the components shown in other figures. Computing system 800 may include, for example, a computer, server, desktop computer, laptop computer, tablet computer, smartphone, or any other suitable computing device. As shown, computing system 800 may include a communication interface 802, processor 804, storage device 806, and input / output (I / O) module 808 communicatively connected via communication infrastructure 810. While an illustrative computing system 800 is shown, the components depicted are not intended to be limiting, and additional or alternative components may be used in other implementations.

[0083] The communication interface 802 can be configured to communicate with one or more other computing devices or networks. Examples of the communication interface 802 may include, but are not limited to, wired network interfaces (such as Ethernet network interface cards), wireless network interfaces (such as Wi-Fi adapters or Bluetooth modules), modems, and any other suitable interfaces for data exchange.

[0084] Processor 804 may be configured to interpret and execute computer-readable instructions and process data. Processor 804 may be an implementation of processor 200 and is configured to perform the adaptive prefetch activation method described herein. In some examples, processor 804 may include a cache, prefetch module, and control unit configured to operate as described herein. For example, processor 804 may direct the execution of operations according to one or more applications 812 or other computer-executable instructions stored in storage device 806.

[0085] Storage device 806 may include one or more data storage media, devices, or configurations, and may take any type, form, and combination of data storage media and / or devices. For example, storage device 806 may include, but is not limited to, hard disk drives, solid-state drives, flash drives, magnetic disks, optical disks, static random access memory (SRAM), dynamic random access memory (DRAM), or any other non-volatile and / or volatile data storage unit. Electronic data, including the data described herein, may be temporarily and / or permanently stored in storage device 806. For example, data representing one or more executable applications 812 configured to direct processor 804 to perform any of the operations described herein may be stored in storage device 806. In some examples, data may be arranged in one or more databases residing within storage device 806.

[0086] Input / output (I / O) module 808 can be configured to receive user input and provide user output. I / O module 808 may include any hardware, firmware, software, or combinations thereof that support input and output capabilities. For example, I / O module 808 may include hardware and / or software for capturing user input, including but not limited to a keyboard, keypad, pointing device, touchscreen assembly, microphone, camera, receiver, motion sensor, and / or one or more input buttons. I / O module 808 may also include one or more devices for presenting output to the user, including but not limited to a graphics engine, display, one or more output drivers, one or more audio speakers, and one or more haptic feedback devices.

[0087] The communication infrastructure 810 can be configured to facilitate communication between various components of the computing system 800. The communication infrastructure 810 may include, but is not limited to, a communication bus, a network, and any other suitable framework for data exchange.

[0088] The following clauses describe how adaptive prefetch activation is implemented in a processor based on the principles described herein.

[0089] Clause 1. A method comprising: performing a prefetch operation by a prefetch module of a processor to prefetch data from a data source into a cache of the processor, the prefetch operation being based on an access pattern detected by the prefetch module; detecting the occurrence of a first condition based on a performance metric associated with the prefetch operation; deactivating the prefetch module based on the occurrence of the first condition; detecting the occurrence of a second condition after the deactivation of the prefetch module; and reactivating the prefetch module based on the occurrence of the second condition.

[0090] Clause 2. The method as described in Clause 1, wherein: the performance metric corresponds to the inefficiency of the prefetch operation; and the occurrence of the first condition is detected based on the performance metric exceeding a predetermined threshold.

[0091] Clause 3. The method as described in Clause 2, wherein the performance metric represents the inefficiency of the prefetch operation as a portion of the prefetch requests performed by the prefetch module during the prefetch operation, the portion including prefetch requests that hit the cache based on previous demand requests.

[0092] Clause 4. The method as described in Clause 2, wherein: the prefetch module is a first prefetch module included in a prefetch unit of the processor having a second prefetch module; and the performance metric represents the inefficiency of the prefetch operation as a portion of a prefetch request performed by the prefetch module during the prefetch operation, the portion including prefetch requests that are hit in the cache based on previous prefetch requests performed by the second prefetch module.

[0093] Clause 5. The method as described in Clause 2, wherein: the prefetch module is a first prefetch module included in a prefetch unit of the processor having a second prefetch module; and the performance metric represents the inefficiency of the prefetch operation as a portion of a prefetch request made by the prefetch module during the prefetch operation, the portion including a prefetch request that matches a pending prefetch request made by the second prefetch module within a request tracking structure.

[0094] Clause 6. The method as described in Clause 1, wherein: the performance metric corresponds to the inaccuracy of the prefetch operation; and the occurrence of the first condition is detected based on the performance metric exceeding a predetermined threshold.

[0095] Clause 7. The method as described in Clause 1, wherein: the processor includes a core configured to access system memory via the cache, the core generates a demand request referenced by instructions executed by the core; the performance metric corresponds to the hit rate of the core for the demand request during the prefetch operation; and the occurrence of the first condition is detected based on the performance metric exceeding a predetermined threshold.

[0096] Clause 8. The method as described in Clause 1, wherein: the performance metric is a first performance metric associated with a request for access to system memory via the cache issued by the core of the processor; the second performance metric is associated with a prefetch request issued by the prefetch module; and the occurrence of the first condition is detected when either the first performance metric exceeds a first predetermined threshold or the second performance metric exceeds a second predetermined threshold.

[0097] Clause 9. The method as described in Clause 1, wherein the detection of the occurrence of the second condition includes determining that the deactivation period has expired.

[0098] Clause 10. The method as described in Clause 9, wherein: prior to the deactivation of the prefetch module, the duration of the deactivation period is determined based on the performance metric associated with the prefetch operation; and the deactivation period expires after the duration.

[0099] Clause 11. The method as described in Clause 1, wherein the detection of the occurrence of the second condition is based on an additional performance metric corresponding to a demand request issued by the processor core when the prefetch module is deactivated.

[0100] Clause 12. The method as described in Clause 11, wherein the occurrence of the second condition is detected when both of the following occur: the deactivation period has expired and the additional performance metric exceeds a predetermined threshold.

[0101] Clause 13. The method as described in Clause 1, wherein: the processor is a multi-core processor, the multi-core processor including a first core, a second core, and a shared cache accessible to the first core and the second core; the cache is a local cache integrated with the first core; and the data source is the shared cache.

[0102] Clause 14. The method as described in Clause 1, wherein: the processor is a multi-core processor, the multi-core processor including a first core, a second core, and a shared cache accessible to the first core and the second core; the cache is the shared cache; and the data source is system memory used by the processor.

[0103] Clause 15. A processor comprising: a cache configured to receive data from a data source; a prefetch module configured to perform a prefetch operation to prefetch data from the data source into the cache, the prefetch operation being based on an access pattern detected by the prefetch module; and a control unit communicatively coupled to the cache and the prefetch module, the control unit being configured to: detect the occurrence of a first condition based on a performance metric associated with the prefetch operation; deactivate the prefetch module based on the occurrence of the first condition; detect the occurrence of a second condition after the deactivation of the prefetch module; and reactivate the prefetch module based on the occurrence of the second condition.

[0104] Clause 16. The processor as described in Clause 15 further includes a prefetch unit having a plurality of prefetch modules including the prefetch module; wherein the control unit is configured to activate the prefetch module by globally deactivating the prefetch unit or by selectively activating the prefetch module independently of other prefetch modules among the plurality of prefetch modules.

[0105] Clause 17. The processor as described in Clause 15, the processor being implemented as a multi-core central processing unit (CPU), the CPU further comprising: a first core; a second core; and a shared cache accessible to the first core and the second core, and implementing the cache or the data source.

[0106] Clause 18. A control unit for a processor having a prefetch module and a cache, the control unit including logic configured to: detect the occurrence of a first condition based on a performance metric associated with a prefetch operation, the prefetch module prefetching data from a data source into the cache via the prefetch operation; deactivate the prefetch module in response to detecting the occurrence of the first condition; detect the occurrence of a second condition after deactivating the prefetch module; and reactivate the prefetch module in response to detecting the occurrence of the second condition.

[0107] Clause 19. The control unit as described in Clause 18, wherein: the performance metric is a first performance metric associated with a request for access to system memory via the cache issued by the core of the processor; a second performance metric is associated with a prefetch request issued by the prefetch module; and the occurrence of the first condition is detected when either the first performance metric exceeds a first predetermined threshold or the second performance metric exceeds a second predetermined threshold.

[0108] Clause 20. The control unit as described in Clause 18, wherein the occurrence of the second condition is detected when both of the following occur: the deactivation period has expired and an additional performance metric exceeds a predetermined threshold, the additional performance metric corresponding to a demand request issued by the processor core when the prefetch module is deactivated.

[0109] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system, which includes at least one programmable processor, which may be dedicated or general-purpose, and is coupled to receive and transmit data and instructions from and to a storage system, at least one input device, and at least one output device.

[0110] Various implementations have been described. It should be understood that various modifications can be made without departing from the spirit and scope of the specification and claims. Furthermore, the logical flow depicted in the figures does not require the desired result to be achieved in the specific order or sequence shown. Additionally, other steps may be provided, or steps may be removed from the described flow, and other components may be added to or removed from the described system. Therefore, other implementations are all within the scope of the appended claims.

[0111] It should be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the implementations of this disclosure. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0112] The terminology used herein is for the purpose of describing a particular implementation only and is not intended to limit the implementation. As used herein, unless the context clearly indicates otherwise, the singular forms “a / an” and “the” are intended to include the plural forms as well. It should be further understood that the terms “comprises, comprising, includes, and / or including” as used in this specification specify the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0113] It should be understood that when an element is referred to as "coupled" or "connected" to another element, the element may be directly coupled or connected to that other element, or there may be an intermediary element. Conversely, when an element is referred to as "directly coupled" or "directly connected" to another element, there is no intermediary element.

[0114] For ease of description, spatially relative terms such as “below,” “under,” “down,” “above,” “above,” etc., may be used herein to describe the relationship between one element or feature and another element or feature as shown in the figures. It should be understood that spatially relative terms are intended to cover different orientations of the device in use or operation, other than those depicted in the figures. For example, if the device in the figures is flipped, an element described as “below” or “under” other elements or features would be oriented as “above” other elements or features. Thus, the term “below” can encompass both above and below orientations. The device may be oriented in other ways (e.g., rotated 90 degrees or in other orientations), and the spatially relative descriptors used herein may be interpreted accordingly.

[0115] Unless otherwise defined, the terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which these concepts belong. It should further be understood that terms such as those defined in common dictionaries should be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and should not be interpreted in an overly formal sense unless expressly defined herein.

[0116] In addition to the description above, users can be provided with controls that allow them to choose whether and when the system, program, or feature described herein enables the collection of user information (e.g., information about the user's social networks, social actions or activities, occupation, user preferences, or the user's current location) and whether to send content or communications to the user from the server. Furthermore, before storing or using certain data, it can be processed in one or more ways to remove personally identifiable information. For example, a user's identity can be processed to make it impossible to determine the user's personally identifiable information, or the user's geographic location can be generalized (e.g., to a city, zip code, or state level) to make it impossible to determine the user's specific location. Therefore, users can control what information is collected from them, how that information is used, and what information is provided to them.

[0117] While certain features of the described implementations have been shown as described herein, many modifications, substitutions, alterations, and equivalents will be apparent to those skilled in the art. Therefore, it should be understood that the appended claims are intended to cover such modifications and alterations falling within the scope of the implementations. It should be understood that they are presented by way of example only and not limitation, and various changes in form and detail are possible. Any part of the apparatus and / or method described herein can be combined in any combination, except for mutually exclusive combinations. The implementations described herein may include various combinations and / or sub-combinations of the functions, components, and / or features of the different implementations described. Thus, the scope of this disclosure is not limited to the specific combinations claimed below, but is instead extended to cover any combination of features or example implementations described herein, regardless of whether that specific combination has been specifically enumerated in the appended claims at this time.

Claims

1. A method comprising: A prefetch operation is performed by the processor's prefetch module to prefetch data from the data source into the processor's cache, the prefetch operation being based on access patterns detected by the prefetch module; The occurrence of the first condition is detected based on performance metrics associated with the prefetch operation; The prefetch module is deactivated based on the occurrence of the first condition; After the prefetch module is deactivated, the occurrence of the second condition is detected; as well as The prefetch module is reactivated based on the occurrence of the second condition.

2. The method of claim 1, wherein: The performance metric corresponds to the inefficiency of the prefetch operation; and The occurrence of the first condition was detected based on the performance metric exceeding a predetermined threshold.

3. The method as described in claim 2, wherein, The performance metric represents the inefficiency of the prefetch operation as a portion of a plurality of prefetch requests performed by the prefetch module during the prefetch operation, the portion including prefetch requests that hit the cache based on previous demand requests.

4. The method of claim 2, wherein: The prefetch module is a first prefetch module included in the prefetch unit of the processor, which has a second prefetch module; and The performance metric represents the inefficiency of the prefetch operation as a portion of a plurality of prefetch requests performed by the prefetch module during the prefetch operation, the portion including prefetch requests that are hit in the cache based on previous prefetch requests performed by the second prefetch module.

5. The method of claim 2, wherein: The prefetch module is a first prefetch module included in the prefetch unit of the processor, which has a second prefetch module; and The performance metric represents the inefficiency of the prefetch operation as a portion of a plurality of prefetch requests made by the prefetch module during the prefetch operation, the portion including prefetch requests that match pending prefetch requests made by the second prefetch module within the request tracking structure.

6. The method of claim 1, wherein: The performance metric corresponds to the inaccuracy of the prefetch operation; and The occurrence of the first condition was detected based on the performance metric exceeding a predetermined threshold.

7. The method of claim 1, wherein: The processor includes a core configured to access system memory via the cache, and the core generates demand requests referenced by instructions executed by the core. The performance metric corresponds to the hit rate of the core for the demand request during the prefetch operation; and The occurrence of the first condition was detected based on the performance metric exceeding a predetermined threshold.

8. The method of claim 1, wherein: The performance metric is a first performance metric associated with a request issued by the processor core for accessing system memory through the cache; The second performance metric is associated with the prefetch request issued by the prefetch module; and The occurrence of the first condition is detected when any of the following conditions are met: The first performance metric exceeds a first predetermined threshold, or The second performance metric exceeds a second predetermined threshold.

9. The method of claim 1, wherein, The detection of the occurrence of the second condition includes determining that the deactivation period has expired.

10. The method of claim 9, wherein: Prior to the deactivation of the prefetch module, the duration of the deactivation period is determined based on the performance metric associated with the prefetch operation; and The deactivation period expires after the duration.

11. The method of claim 1, wherein, The detection of the occurrence of the second condition is based on additional performance metrics corresponding to the demand request issued by the processor core when the prefetch module is deactivated.

12. The method of claim 11, wherein, The second condition is detected when either of the following conditions is met: The deactivation period has expired, and The additional performance metric exceeds a predetermined threshold.

13. The method of claim 1, wherein: The processor is a multi-core processor, which includes a first core, a second core, and a shared cache accessible to the first core and the second core. The cache is a local cache integrated with the first core; and The data source is the shared cache.

14. The method of claim 1, wherein: The processor is a multi-core processor, which includes a first core, a second core, and a shared cache accessible to the first core and the second core. The cache is the shared cache; and The data source is the system memory used by the processor.

15. A processor, comprising: A cache, configured to receive data from a data source; A prefetch module, configured to perform a prefetch operation to prefetch data from the data source into the cache, the prefetch operation being based on an access pattern detected by the prefetch module; as well as A control unit, communicatively coupled to the buffer and the prefetch module, is configured to: The occurrence of the first condition is detected based on performance metrics associated with the prefetch operation; The prefetch module is deactivated based on the occurrence of the first condition; After the prefetch module is deactivated, the occurrence of the second condition is detected; as well as The prefetch module is reactivated based on the occurrence of the second condition.

16. The processor of claim 15, further comprising a prefetch unit, the prefetch unit having a plurality of prefetch modules including the prefetch module; in, The control unit is configured to activate the prefetch module either globally or selectively, independently of other prefetch modules among the plurality of prefetch modules.

17. The processor of claim 15, wherein, The processor is implemented as a multi-core central processing unit (CPU), and wherein the multi-core CPU further comprises: The first core; The second core; and A shared cache, which is accessible to both the first core and the second core, and which implements the cache or the data source.

18. A control unit for a processor having a prefetch module and a cache, the control unit including circuitry configured to: The occurrence of the first condition is detected based on performance metrics associated with the prefetch operation, through which the prefetch module prefetches data from the data source into the cache; In response to detecting the occurrence of the first condition, the prefetch module is deactivated; After deactivating the prefetch module, the occurrence of the second condition is detected; as well as In response to the detection of the occurrence of the second condition, the prefetch module is reactivated.

19. The control unit of claim 18, wherein: The performance metric is a first performance metric associated with a request issued by the processor core for accessing system memory through the cache; The second performance metric is associated with the prefetch request issued by the prefetch module; and The occurrence of the first condition is detected when any of the following conditions are met: The first performance metric exceeds a first predetermined threshold, or The second performance metric exceeds a second predetermined threshold.

20. The control unit as claimed in claim 18, wherein, The second condition is detected when either of the following conditions is met: The deactivation period has expired, and An additional performance metric exceeds a predetermined threshold, the additional performance metric corresponding to a demand request issued by the processor core when the prefetch module is deactivated.

Images