Supporting adaptive shared cache management

Embodiment of this disclosure provides a mechanism to use a portion of an inactive processing element's private cache as an extended last-level cache storage space to adaptively adjust the size of shared cache. In one embodiment, a processing device is provided. The processing device comprising a cache controller is to identify a cache line to evict from a shared cache. An inactive processing core is selected by the cache controller from a plurality of processing cores associated with the shared cache. Then, a private cache of the inactive processing core is notified of an identifier of a cache line associated with the shared cache. Thereupon, the cache line is evicted from the shared cache to install in the private cache.

TECHNICAL FIELD

Embodiments of the disclosure relate generally to computer processor architectures, and more specifically, but without limitation, to supporting adaptive shared cache management.

BACKGROUND

Multi-core processors are found in most computing systems today, including servers, desktops and a System on a Chip (SoC). Such multi-core processors may include cache memory that is used for high-speed multi-threaded applications to support, for example, various types of parallel computing.

DETAILED DESCRIPTION

Computing systems may achieve high performance and energy efficiency by incorporating certain processing elements (e.g., processing cores and/or special purpose processors comprising a plurality of processing cores) to handle specific computing tasks. In such systems, these processing elements may share common hardware components that include, but not limited to, on-die fabric, shared caches, in-package memory, network fabric, etc. To achieve high performance, each of the processing elements may be associated with cache memory. For example, in order to reduce memory access time in these types of systems, a high-speed memory called a “cache” is used to temporarily store lines of data (also referred to as a cache lines) which are currently in use by a processing element.

A “cache line” is a basic unit of storage in a cache. The cache line can include a copy of instructions and/or data obtained from main memory for quick access by the processing element. Data stored in the cache may be accessed by the processing element, rather than stalling and waiting for the retrieval of this data from the main memory. For example, when the processing element requests a data item from the main memory, the cache is accessed first for the data when the processing element processes a memory access instruction. If the data item is not in cache also referred to as a cache “miss”, the data is then retrieved from main memory and copied into the cache.

The cache may be associated with a cache hierarchy that includes a private cache accessible only by a particular processing element and a shared cache that is accessible to all of the processing elements. The cache hierarchy may include, for example, multiple levels referred to as L1, L2 and L3. The L1 and L2 levels are private to each processing elements while the level L3 also referred to as the Last Level Cache (LLC) is shared between processing elements. The cache hierarchy is designed to provide different fast cache access latencies. For example, the L1 cache is the smallest of the levels that runs at the fastest speed, the L2 cache is the next smallest level that runs at the next fastest speed, while the LLC shared cache is the largest (e.g., several megabytes in size) and runs at the slowest speed. The LLC is usually accessed if the data requested in a memory access request cannot be found in L1 or L2. If this data item is not in the LLC also referred to as a cache “miss”, the data is then copied into the cache from main memory.

Certain applications executing on the computing system may display different memory access behavior based on the cache configuration. For example, some applications perform better when more private data is kept in the cache. In view of this, because the total on-die cache storage is constrained by the physical size of the die, more cache may be reserved privately for each individual processing element leaving less die area available for the shared cache. These types of cache capacity constraints, however, can lead to adverse system performance issues. For example, in order to make room for a new entry in the LLC on a cache miss, the cache may have to evict an existing cache line (victim line) due the constraints on the size of the cache. When a subsequent request to the victim line is received, this generates a memory access to bring the line back to the cache system again. In this regard, such misses related to the limited cache capacity can greatly degrade the performance of the system and exacerbate memory bandwidth usage in the system.

Embodiments of the disclosure address the above-mentioned problems and other deficiencies by providing techniques to use a portion of an inactive processing element's (e.g., processing core) private cache as extended LLC storage space to adaptively adjust the shared cache size. In this way, the shared cache capacity of the system can increase without the necessity of adding hardware storage/cost or sacrificing performance tradeoffs. In most computing systems, all processing elements are not active at the same time. Once a processing element becomes inactive, the private cache (e.g., L2) associated with that element may be turned off. In embodiments, the cache controller may implement adaptive shared cache logic (e.g., hardware component, circuitry, dedicated logic, programmable logic, microcode, etc.) to reclaim the private cache from inactive processing elements (e.g., processing cores). The reclaimed private cache storage may then be used by the cache controller as an extended portion of the LLC for storing data, rather than sending that data back to main memory.

In operation, the cache controller may identify a cache line (e.g., victim line) to evict from the LLC when space in the LLC is needed for a new cache-line. For example, a least-recently-used (LRU) algorithm or other type of similar methods may be used to select a victim line to remove from the LLC. Instead of immediately sending the victim line back to main memory, the cache controller may determine whether there is a private cache storage associated with an inactive processing element that can be used as shared cache storage. In one embodiment, the active status of the processing cores may be tracked by hardware. In other embodiments, the system software (e.g., host operating system) may include information on which processing elements are active and inactive. The cache controller may receive this information from the system software to identify a potential target (e.g., inactive processing element) for installing the victim line.

In some embodiment, the cache controller transmits a message (e.g., a prefetch hint) to the target (e.g., an inactive processing element) to request if the victim line can be installed or otherwise prefetched into the target's unused private cache. This message may include an identifier (e.g., a memory address) of the victim line to be written to the L2 level of the private cache of the target. The LLC cache controller may then receive a read request from the target of data for the victim line. This read request of the victim line in the LLC indicates that the target is confirming the request to prefetch the victim line based on the prefetch hint. For example, a processing element can sometimes prefetch data before it is needed by the processor. The prefetch can either be triggered by software or hardware of the processor. In some implementations, the shared cache controller sends hints (prefetch hint) to the processing element to suggest the next request address that should be prefetched. In some embodiments, the cache controller may engage the prefetch hint implementation using a prefetch hint message to initiate an operation by the inactive processing element to prefetch the LLC victims. Once the controller associated with the inactive processing element receives such messages, it brings the victims into its unused private cache storage.

Any active processing element that makes a subsequent memory request to the victim line may obtain that line from the inactive element's private L2 as part of a cache-to-cache transfer of the data, rather than a slower retrieval of the data from main memory. The victim line, in embodiments, is written to the L2 level of the private cache. As a result, if the inactive processing element becomes active again the victim line may be routinely written back to the LLC by the processing element. For example, when the computing system is powered off and then back on, some systems may flush the private cache back to the LLC.

In some embodiments, if the processing element becomes active again, it may start fetching new data items (e.g., from main memory) to put in the private cache. In such cases, as space gets used in the L2 caches, the processing element may, as part of its routine procedures, evict cache lines to main memory create more space. In other embodiments, the cache controller may be configured to trigger a flush of the victim line out of the private cache. For example, the eviction of the victim line may be triggered by the local L2 private cache running out of space, and, therefore, triggers existing eviction procedures that evicts the victim line out of the inactive processing core's private cache to the main memory or the newly available memory space in the LLC.

Embodiments of the disclosure may be advantageous for improving processor performance by providing an adaptive size shared cache that can reduce cache capacity misses. In this way, it lowers memory bandwidth usage by reducing the active memory traffic caused by capacity misses, thereby proportionally reducing the memory controller's power consumption. This is because the memory access resulting from a cache “miss” uses more power than a core to core transfer to retrieve the victim line from the inactive core. Another advantage of the techniques disclosed herein is that application developers can enable different cache blocking and prefetching techniques to further optimize the execution of their programs. Moreover, the various techniques and parameters disclosed within may be further scaled to provide additional benefits. For example, if only a first portion of the inactive processing element's L2 cache is used as part of the adaptive LLC, the second portion can be powered down while the other is used further optimizing the power/performance of the processor.

FIG. 1illustrates a block diagram of a processing device100for supporting adaptive shared cache management according to one embodiment. The processing device100may be generally referred to as “processor” or “CPU”. “Processor” or “CPU” herein shall refer to a device that is capable of executing instructions encoding arithmetic, logical, or I/O operations. In one illustrative example, a processor may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. In a further aspect, a processor may include one or more processing cores, and hence may be a single core processor which is typically capable of processing a single instruction pipeline, or a multi-core processor which may simultaneously process multiple instruction pipelines. In another aspect, a processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket).

As shown inFIG. 1, processing device100may include various components. In one embodiment, processing device100may include one or more processors cores110and a memory controller unit120, among other components, coupled to each other as shown. The processing device100may also include a communication component (not shown) that may be used for point-to-point communication between various components of the processing device100. The processing device100may be used in a computing system (not shown) that includes, but is not limited to, a desktop computer, a tablet computer, a laptop computer, a netbook, a notebook computer, a personal digital assistant (PDA), a server, a workstation, a cellular telephone, a mobile computing device, a smart phone, an Internet appliance or any other type of computing device. In another embodiment, the processing device100may be used in a system on a chip (SoC) system. In one embodiment, the SoC may comprise processing device100and a memory. The memory for one such system is a DRAM memory. The DRAM memory can be located on the same chip as the processor and other system components. Additionally, other logic blocks such as a memory controller or graphics controller can also be located on the chip.

In some embodiments, the processing device100may execute one or more application programs (not shown) (e.g., a user-level multithreaded application). Such application programs may be executed by system software (not shown) installed at the processing device100. Examples of system software include, but are not limited to, one or more operating systems, a virtual machine monitor (VMM), a hypervisor, and the like, and combinations thereof. The application programs may use instructions to control the processing device100as disclosed herein. The instructions may represent macro-instructions, assembly language instructions, or machine-level instructions that are provided to the processing core110for execution.

The processor core(s)110may execute instructions for the processing device100. The instructions may include, but are not limited to, pre-fetch logic to fetch instructions, decode logic to decode the instructions, execution logic to execute instructions and the like. The computing system may be representative of processing systems based on the Pentium® family of processors and/or microprocessors available from Intel® Corporation of Santa Clara, Calif., although other systems (including computing devices having other microprocessors, engineering workstations, set-top boxes and the like) may also be used. In one embodiment, a sample computing system may execute a version of an operating system, embedded software, and/or graphical user interfaces. Thus, embodiments of the disclosure are not limited to any specific combination of hardware circuitry and software.

In an illustrative example, processing core110may have a micro-architecture including processor logic and circuits. Processor cores with different micro-architectures can share at least a portion of a common instruction set. For example, similar register architectures may be implemented in different ways in different micro-architectures using various techniques, including dedicated physical registers, one or more dynamically allocated physical registers using a register renaming mechanism (e.g., the use of a register alias table (RAT), a reorder buffer (ROB) and a retirement register file).

Memory controller unit120may perform functions that enable the processing device100to access and communicate with memory (not shown) that includes a volatile memory and/or a non-volatile memory. In some embodiments, the memory controller unit120may be located on a processor die associated with processing device100, while the memory is located off the processor die. In some embodiments, each processing core110of the processing device100may have a corresponding cache unit130to cache instructions and/or data. The cache unit130includes, but is not limited to, level one (L1)132, level two (L2)134, and last level cache (LLC)136, or any other configuration of cache memory. For example, the adaptive shared cache is applicable to a variety of cache memory configurations with or without L1, with or without L2, but at least have one level of private cache (usually called L1 if there is only one level) and an LLC (L3).

A “cache” or “cache memory” as used herein, including the L1 cache132, L2 cache134and LLC136, may be a hardware component associated with the processing device100that stores cache lines for use by the processor cores110. The processor cores110may access a cache line within a cache using any operation/instruction (e.g., performing arithmetic or logic functions). A cache line may be a basic unit of storage in a cache and may be referred to as a block or a sector of memory (e.g., a cache) that may be managed as a unit for coherence purposes. In some embodiments, a cache line within a cache may be between 16-256 bytes. A cache line may be stored in cache memory (e.g., in a L1 cache132, L2 cache134and LLC136), system memory, or combinations thereof. The cache memory may refer to a memory buffer inserted between one or more processors on a bus (not shown), for example, to store/hold currently active copies of cache lines, (e.g., blocks from system (main) memory).

The LLC136, in embodiments, may be shared by multiple processing cores110of processing device100, and consequently threads executing on each of these cores, or local/dedicated/private to single core of a processor (e.g., not shared). In that regard, the L1 cache132and L2 cache134may be private, dedicated, and or local to a processing core110. In some embodiments, the L1 cache132and L2 cache134operate at a lower-level in the cache unit130than the shared cache LLC136. In one embodiment, the memory controller unit120can be connected to the LLC136to transfer data between the cache unit130and memory. As shown, the cache unit130can be integrated into the processing cores110. The cache unit130may store data (e.g., including instructions) that are utilized by one or more components of the processing device100.

The L1 cache132and L2 cache134can transfer data to and from the LLC136. For example, the processing device100may include an on-die fabric (not shown) that couples the processing cores110and their corresponding private caches (e.g., L1 cache132and L2 cache134) to the shared cache LLC136, via a cache controller140. The cache controller140may be a hardware and/or software component that implements adaptive shared cache circuit145to reclaim a portion of an inactive processing cores'113private cache. For example, the reclaimed private cache may be used to adaptively adjust the shared cache size utilized in the processing device100. Embodiments described herein may be implemented as a set of instructions147in the adaptive shared cache circuit145. In some embodiments, the processor cores110of the processing device100may execute the instructions147of the adaptive shared cache circuit145to provide the benefits of the techniques disclosed herein. For example, the instructions147of the adaptive shared cache circuit145may instruct the cache controller140to evict a cache line115from the LLC to be installed in the inactive core113's private cache. Thereby, increasing the available size of the shared cache memory used for high-speed multi-threaded applications without incurring additional cost or performance tradeoffs. As discussed herein, “logic” may refer to hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), firmware, or any combination thereof.

FIG. 2illustrates a block diagram of a system200including a data structure (such as coherence directory201) to support adaptive shared cache management according to one embodiment. The coherency directory201is a block of memory which keeps track of which processing cores210,220in a multiprocessor computer system, such as system200, owns which lines of memory. The system200may be the same as processing device100and include the adaptive shared cache circuit145ofFIG. 1. In some embodiments, the system200includes a plurality of processing cores210and220that may be the same as the processing cores110ofFIG. 1. Each of the processing cores210and220includes cache memory215,225. This cache memory215,225may be private to the respective processing cores210and220. For example, cache memory215may be an L2 level private cache of processing cores210and cache memory225may be an L2 level private cache of processing cores220. In some embodiments, the system200may be associated with a shared cache memory LLC230(which may be the same as LLC336ofFIG. 1) that can be shared by the plurality of processing cores210and220.

Each of the cache memories215,225and235is comprised of a number of cache lines213,223and233, respectively. The cache lines213,223and233can include a copy of instructions and/or data obtained from main memory for quick access by the processing cores210and220. In some embodiments, cache memory215,225and235is associated with a number of controllers includes controllers211,221and231. Each of the controllers211,221and231may include multiple controllers that can be located inside or outside of a cache memory. The controllers211,221and231manage activities of the corresponding cache memories215,225and235including adding and evicting the cache lines213,223and233from the cache memories215,225and235.

To keep track of the cache lines213,223and233with respect to the cache memories215,225and235, the system200may include a data structure also referred to as coherence directory201that is a block of memory comprising a number of entries203. Although embodiments of the disclosure as discussed with respect to a coherence directory201, other types of data structures may be implemented by system200to keep track of the cache lines213,223and233. In this embodiment, the coherence directory201may be a table or other types of similar data structures to store “coherence data” relating to the cache memories215,225and235. The coherence data may include information to maintain the consistency of the main memory data that ends up stored in multiple caches. For example, the coherence directory201may include coherence data, such as an entry for each cache line213,223,233of the cache memories215,225and235in the system200. Each entry203includes a number of data fields, such as a memory line202which may be an identifier of a memory address of a cache line, location information204(e.g., an identifier of a processing core associated with the cache line), as well as other data206used to keep track of the cache lines213,223,233.

The processing cores210and220of system200operate with respect to the cache memories215,225and235by initiating a memory request. For example, an application executed by the processing cores210and220may initiate a memory operation that includes a memory request to access a particular memory address. In one embodiment, a “hit” occurs if the cache (e.g., cache235) associated with the processing core (e.g., core220) stores data for the memory request. In one embodiment, a “miss” occurs if the cache225does not store the cache line requested by the memory request of the processing core220. If a “miss” occurs during a memory request to the cache line in the cache225, the processing core220requests corresponding data from LLC230and fills that data in the cache.

When the controller231associated with the LLC230receives the memory request, it looks for the cache line in the LLC230. If a “miss” occurs during a memory request to a cache line in the LLC230, the cache line is retrieved from main memory and stored in the LLC. In some situations, the retrieval and storage of the cache line the LLC230may cause the controller231to select a victim line to evict back to the main memory in order to create space for the new cache line. Instead of immediately sending this victim line back to main memory, the adaptive shared cache circuit145may instruct the controller231to determine whether there is an inactive processing core that can be used as shared cache storage to store the victim line. For example, all of the processing cores210,220of system200are not active at the same time. When a processing core (e.g., such as processing core210) becomes inactive, the private cache215may be reclaimed and used as an extended portion of the LLC230for storing the victim line, rather than sending that line back to main memory.

In operation, the controller231as directed by the adaptive shared cache circuit145the may initially identify a victim line (e.g., cache line X232) to evict from the shared cache memory (e.g., LLC230.) There are, for example several ways that this victim line X232from the LLC230may be identified. In one embodiment, the victim line X232may be selected based on a least-recently-used (LRU) algorithm. The LRU algorithm may be used to identify a victim (cache) line that has not been used for a threshold amount of time. The LRU cache line may be identified based on a counter237or a logical clock (such as a hardware register) that can be used to determine the amount of time since the last request to the victim line.

Each cache line233of the LLC230, in embodiments, may be associated with a counter237that is adjusted in accordance with the LRU algorithm. Each cache line read out of main memory into the LLC230, the counter237for that line is initialized to 0. Each time that cache line is accessed by a processing core, its counter237is incremented. This method requires equipping the hardware with a 64-bit counter (e.g., counter237) that is automatically incremented after each instruction. As such, the counter with the lowest counter may be selected as the least recently used by the LRU algorithm. In alternative embodiments, other algorithms, such as an aging, random selection algorithm, etc., which (are either based or not based on the counter237) can be implemented to select a victim line X232to evict from the LLC230to install in the inactive processing core210.

Thereupon, the controller231may select an inactive processing core210among the processing cores210,220of system200. The inactive processing core210may be identified as a potential target to write out information associated with the victim line X232. For example, system200may include information on which processing cores are active and inactive. The controller231may receive this information from, for example, system software and/or hardware, to identify the potential target (e.g., inactive processing core210) for installing the victim line. The controller231may detect the inactive processing core210by selecting cores that have executed a “HALT” instruction if such an instruction is supported by the instruction set architecture (ISA) of the processing device. In some embodiments, the LLC230can track the active and inactive processing cores. For example, system software can update a status registers for LLC230to track the inactive cores at 1) system startup time or 2) during the procedure in which one of the processing cores goes from active to inactive. In some embodiments, the controller231may choose co-located cores within a particular interconnect that couples all the processing cores to select the inactive processing core210that is, e.g., the shortest distance to move the data. In an alternative embodiment, the controller231can use the cacheline address of the victim line X232to select an inactive processing core210.

To determine whether inactive processing core210will accept the victim line X232, the controller231may transit a message240using, for example, an inter-core communication protocol that facilitates message communication between the cores210,220of the system200. In some embodiments, the message240may be between by the cores210,220via a data bus or interconnect of system200. In some embodiments, the message240includes a prefetch hint240to initiate a prefetch of the victim line X232into cache memory215of the inactive processing core210. In this regard, the controller211of the inactive processing core210may receive the message and then preform a prefetch of the victim line X232. For example, a processing core can sometimes prefetch data before it is needed by the processor. The prefetch can either be triggered by software or hardware of the processor. In some implementations, the shared cache controller231sends hints (prefetch hint240) to the processing core210to initiate an operation by the inactive processing core210to prefetch the victim line X232from the LLC230, and install the line into the core's unused private cache storage (e.g., cache memory215).

In most of the cases, the controller211of the inactive processing core210may always try to install the victim lines. In some cases, when there is an internal hardware conflicts in the controller211, it can decide not to bring the victim lines. The controller211still needs to respond to the LLC's controller231to indicate the line cannot be brought in. Under such circumstances, the LLC230may then evict the victim line X232back to the main memory. In other cases, it is possible that in between sending and receiving the prefetch hint message240, the inactive core210becomes active again, e.g. due to an interrupt or other event. In that case, the core210may choose to ignore the prefetch hint240request, and may send back a negative-acknowledgement so that coherence directory201does not associate the victim line X232with core210.

If the inactive core accepts the request, the controller231of the LLC230may receive a read request250from the private cache210of the inactive core210for data of the victim line X232. For example, the read request250may include an identifier (e.g., memory address) of the victim line X232. The controller231may then provide or otherwise forward the data to the private cache215of the inactive processing core210responsive to the read request250, which then writes the data of the victim line X232to the private cache (e.g. L2 cached)215of the inactive processing core210. For example, the controller231creates a copy of the victim line X232in an available space in the private cache215of the inactive processing core210. Thereupon, an entry in the coherence directory201for the victim line X232is updated to indicate that the line is located in the cache of the inactive processing core210.

If an active processing core of system200makes a subsequent memory request to the victim line X232, it may obtain that line from the private cache215of the inactive processing core210. For example, if core220initiates a read memory request270of the victim line X232from the LLC230, the controller231may add additional information (e.g., an identifier) on to the request to indicate a state of the victim line X232and where the cache line is cached. In that regard, the memory request270may be forward (e.g., snooping forward) by the controller231to the private L2 cache memory215of the inactive processing core210for the active core220to read the cache line X232installed therein. For example, the “snoop forward” is a message290generated by the LLC controller231responsive to the “Read X270” message. The purpose of the message is to ask controller211to provide a copy of data X232to the core220.

If the inactive processing core210becomes active again, the victim line X232may be evicted320out of the private cache backed to main memory as part of the normal cache memory operations of system200. For example, another view300of system200is shown inFIG. 3. In this example, processing core210may have been reactivated. For example, the processing core210may be brought back to activity, which triggers310a flush of the private cache215that evicts320all of the private cache lines back to main memory. In another example, when the inactive processing core210is reactivated, the private cache215may start fetching new data lines, which may evict the victim line X232back to main memory if the private cache215runs out of space. Thereupon, the entry in the coherence directory201for the victim line X232is deleted to indicate that the line is no longer cached.

FIG. 4illustrates a flow diagram of a method400for supporting adaptive shared cache management according to one embodiment. Method400may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), firmware, or a combination thereof. In one embodiment, the memory controller140of processing device100inFIG. 1as directed by the adaptive shared cache circuit145may perform method400. Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated implementations should be understood only as examples, and the illustrated processes can be performed in a different order, and some processes may be performed in parallel. Additionally, one or more processes can be omitted in various embodiments. Thus, not all processes are required in every implementation. Other process flows are possible.

Method400begins at block410where a cache (victim) line232to evict from shared cache230is determined. The shared cache230is shared with a plurality of processing cores210,220. For example, victim line232may be selected based on a least-recently-used (LRU) algorithm. The LRU algorithm may be used to identify a victim line232that has not been used for a threshold amount of time. The LRU cache line may be identified based on a counter237or a logical clock (such as a hardware register) that can be used to determine the amount of time since the last request to the victim line.

In block420, an inactive processing core210is selected from a plurality of processing cores210,220associated with the shared cache230. For example, a host operating system may include information that previously identifies which processing cores are active and inactive. This information may be used to select a potential target (e.g., inactive processing core210) for installing the victim line232.

In block430, a private cache215of the inactive processing core210is notified of an identifier X232of the cache line232. For example, once the inactive processing core210is selected, in block420, a message240(e.g., prefetch hint) is transmitted to the core210. The prefetch hint initiates a prefetch operation by the inactive processing core210to prefetch the victim line232into its private cache memory215.

In block440, the cache line232is forwarded from the shared cache232to install in the private cache215. For example, a copy of the victim line X232is transmitted to cache controller211of the inactive processing core210to be installed in an available space in the private cache215. Thereupon, an entry in the coherence directory201for the victim line X232is updated to indicate that the line is now located in the cache215of the inactive processing core210. After forwarding the victim line X232to the inactive core210, the shared cache controller231can safely evict the line from shared cache235in order to make more room.

FIG. 5Ais a block diagram illustrating a micro-architecture for a processor500that implements techniques for supporting adaptive shared cache management functionality in accordance with one embodiment of the disclosure. Specifically, processor500depicts an in-order architecture core and a register renaming logic, out-of-order issue/execution logic to be included in a processor according to at least one embodiment of the disclosure.

Processor500includes a front-end unit530coupled to an execution engine unit550, and both are coupled to a memory unit570. The processor500may include a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, processor500may include a special-purpose core, such as, for example, a network or communication core, compression engine, graphics core, or the like. In one embodiment, processor500may be a multi-core processor or may part of a multi-processor system.

The front end unit530includes a branch prediction unit532coupled to an instruction cache unit534, which is coupled to an instruction translation lookaside buffer (TLB)536, which is coupled to an instruction fetch unit538, which is coupled to a decode unit540. The decode unit540(also known as a decoder) may decode instructions, and generate as an output one or more micro-operations, micro-code entry points, microinstructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions. The decoder540may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read only memories (ROMs), etc. The instruction cache unit534is further coupled to the memory unit570. The decode unit540is coupled to a rename/allocator unit552in the execution engine unit550.

The execution engine unit550includes the rename/allocator unit552coupled to a retirement unit554and a set of one or more scheduler unit(s)556. The scheduler unit(s)556represents any number of different schedulers, including reservations stations (RS), central instruction window, etc. The scheduler unit(s)556is coupled to the physical register file(s) unit(s)558. Each of the physical register file(s) units558represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, etc., status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. The physical register file(s) unit(s)558is overlapped by the retirement unit554to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a retirement register file(s), using a future file(s), a history buffer(s), and a retirement register file(s); using a register maps and a pool of registers; etc.). The execution engine unit550may include for example a power management unit (PMU)590that governs power functions of the functional units.

Generally, the architectural registers are visible from the outside of the processor or from a programmer's perspective. The registers are not limited to any known particular type of circuit. Various different types of registers are suitable as long as they are capable of storing and providing data as described herein. Examples of suitable registers include, but are not limited to, dedicated physical registers, dynamically allocated physical registers using register renaming, combinations of dedicated and dynamically allocated physical registers, etc. The retirement unit554and the physical register file(s) unit(s)558are coupled to the execution cluster(s)560. The execution cluster(s)560includes a set of one or more execution units562and a set of one or more memory access units564. The execution units562may perform various operations (e.g., shifts, addition, subtraction, multiplication) and operate on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point).

While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. The scheduler unit(s)556, physical register file(s) unit(s)558, and execution cluster(s)560are shown as being possibly plural because certain embodiments create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline that each have their own scheduler unit, physical register file(s) unit, and/or execution cluster—and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of this pipeline has the memory access unit(s)564). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.

The set of memory access units564is coupled to the memory unit570, which may include a data prefetcher580, a data TLB unit572, a data cache unit (DCU)574, and a level 2 (L2) cache unit576, to name a few examples. In some embodiments DCU574is also known as a first level data cache (L1 cache). The DCU574may handle multiple outstanding cache misses and continue to service incoming stores and loads. It also supports maintaining cache coherency. The data TLB unit572is a cache used to improve virtual address translation speed by mapping virtual and physical address spaces. In one exemplary embodiment, the memory access units564may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit572in the memory unit570. The L2 cache unit576may be coupled to one or more other levels of cache and eventually to a main memory.

In one embodiment, the data prefetcher580speculatively loads/prefetches data to the DCU574by automatically predicting which data a program is about to consume. Prefeteching may refer to transferring data stored in one memory location of a memory hierarchy (e.g., lower level caches or memory) to a higher-level memory location that is closer (e.g., yields lower access latency) to the processor before the data is actually demanded by the processor. More specifically, prefetching may refer to the early retrieval of data from one of the lower level caches/memory to a data cache and/or prefetch buffer before the processor issues a demand for the specific data being returned.

In one implementation, processor500may be the same as processing device100described with respect toFIG. 1to implement techniques for supporting adaptive shared cache management with respect to implementations of the disclosure.

The processor500may support one or more instructions sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technologies of Sunnyvale, Calif.; the ARM instruction set (with optional additional extensions such as NEON) of ARM Holdings of Sunnyvale, Calif.).

FIG. 5Bis a block diagram illustrating an in-order pipeline and a register renaming stage, out-of-order issue/execution pipeline implemented by processor500ofFIG. 5Aaccording to some embodiments of the disclosure. The solid lined boxes inFIG. 5Billustrate an in-order pipeline, while the dashed lined boxes illustrate a register renaming, out-of-order issue/execution pipeline. InFIG. 5B, a processor pipeline501includes a fetch stage502, a length decode stage504, a decode stage506, an allocation stage508, a renaming stage510, a scheduling (also known as a dispatch or issue) stage512, a register read/memory read stage514, an execute stage516, a write back/memory write stage518, an exception handling stage522, and a commit stage524. In some embodiments, the ordering of stages502-524may be different than illustrated and are not limited to the specific ordering shown inFIG. 5B.

FIG. 6illustrates a block diagram of the micro-architecture for a processor600that includes logic circuits to implement techniques for supporting data compression using match-scoring functionality in accordance with one embodiment of the disclosure. In some embodiments, an instruction in accordance with one embodiment can be implemented to operate on data elements having sizes of byte, word, double word, quad word, etc., as well as datatypes, such as single and double precision integer and floating point datatypes. In one embodiment the in-order front end601is the part of the processor600that fetches instructions to be executed and prepares them to be used later in the processor pipeline.

The front end601may include several units. In one embodiment, the instruction prefetcher626fetches instructions from memory and feeds them to an instruction decoder628, which in turn decodes or interprets them. For example, in one embodiment, the decoder decodes a received instruction into one or more operations called “micro-instructions” or “micro-operations” (also called micro op or uops) that the machine can execute. In other embodiments, the decoder parses the instruction into an opcode and corresponding data and control fields that are used by the micro-architecture to perform operations in accordance with one embodiment. In one embodiment, the trace cache630takes decoded uops and assembles them into program ordered sequences or traces in the uop queue634for execution. When the trace cache630encounters a complex instruction, the microcode ROM632provides the uops needed to complete the operation.

Some instructions are converted into a single micro-op, whereas others need several micro-ops to complete the full operation. In one embodiment, if more than four micro-ops are needed to complete an instruction, the decoder628accesses the microcode ROM632to do the instruction. For one embodiment, an instruction can be decoded into a small number of micro ops for processing at the instruction decoder628. In another embodiment, an instruction can be stored within the microcode ROM632should a number of micro-ops be needed to accomplish the operation. The trace cache630refers to an entry point programmable logic array (PLA) to determine a correct microinstruction pointer for reading the micro-code sequences to complete one or more instructions in accordance with one embodiment from the micro-code ROM632. After the microcode ROM632finishes sequencing micro-ops for an instruction, the front end601of the machine resumes fetching micro-ops from the trace cache630.

The out-of-order execution engine603is where the instructions are prepared for execution. The out-of-order execution logic has a number of buffers to smooth out and re-order the flow of instructions to optimize performance as they go down the pipeline and get scheduled for execution. The allocator logic allocates the machine buffers and resources that each uop needs in order to execute. The register renaming logic renames logic registers onto entries in a register file. The allocator also allocates an entry for each uop in one of the two uop queues, one for memory operations and one for non-memory operations, in front of the instruction schedulers: memory scheduler, fast scheduler602, slow/general floating point scheduler604, and simple floating point scheduler606. The uop schedulers602,604,606, determine when a uop is ready to execute based on the readiness of their dependent input register operand sources and the availability of the execution resources the uops need to complete their operation. The fast scheduler602of one embodiment can schedule on each half of the main clock cycle while the other schedulers can only schedule once per main processor clock cycle. The schedulers arbitrate for the dispatch ports to schedule uops for execution.

Register files608,610sit between the schedulers602,604,606, and the execution units612,614,616,618,620,622,624in the execution block611. There is a separate register file608,610, for integer and floating-point operations, respectively. Each register file608,610, of one embodiment also includes a bypass network that can bypass or forward just completed results that have not yet been written into the register file to new dependent uops. The integer register file608and the floating-point register file610are also capable of communicating data with the other. For one embodiment, the integer register file608is split into two separate register files, one register file for the low order 32 bits of data and a second register file for the high order 32 bits of data. The floating-point register file610of one embodiment has 128 bit wide entries because floating-point instructions typically have operands from 64 to 128 bits in width.

The execution block611contains the execution units612,614,616,618,620,622,624, where the instructions are actually executed. This section includes the register files608,610, that store the integer and floating point data operand values that the microinstructions need to execute. The processor600of one embodiment is comprised of a number of execution units: address generation unit (AGU)612, AGU614, fast ALU616, fast ALU618, slow ALU620, floating point ALU622, floating point move unit624. For one embodiment, the floating-point execution blocks622,624, execute floating point, MMX, SIMD, and SSE, or other operations. The floating point ALU622of one embodiment includes a 64 bit by 64 bit floating point divider to execute divide, square root, and remainder micro-ops. For embodiments of the disclosure, instructions involving a floating-point value may be handled with the floating-point hardware.

In one embodiment, the ALU operations go to the high-speed ALU execution units616,618. The fast ALUs616,618, of one embodiment can execute fast operations with an effective latency of half a clock cycle. For one embodiment, most complex integer operations go to the slow ALU620as the slow ALU620includes integer execution hardware for long latency type of operations, such as a multiplier, shifts, flag logic, and branch processing. The AGUs612,614, executes memory load/store operations. For one embodiment, the integer ALUs616,618,620, are described in the context of performing integer operations on 64 bit data operands. In alternative embodiments, the ALUs616,618,620, can be implemented to support a variety of data bits including 16, 32, 128, 256, etc. Similarly, the floating-point units622,624, can be implemented to support a range of operands having bits of various widths. For one embodiment, the floating-point units622,624, can operate on 128 bits wide packed data operands in conjunction with SIMD and multimedia instructions.

In one embodiment, the uops schedulers602,604,606, dispatch dependent operations before the parent load has finished executing. As uops are speculatively scheduled and executed in processor600, the processor600also includes logic to handle memory misses. If a data load misses in the data cache, there can be dependent operations in flight in the pipeline that have left the scheduler with temporarily incorrect data. A replay mechanism tracks and re-executes instructions that use incorrect data. Only the dependent operations need to be replayed and the independent ones are allowed to complete. The schedulers and replay mechanism of one embodiment of a processor are also designed to catch instruction sequences for text string comparison operations.

The processor600also includes logic to implement support adaptive shared cache circuit145according to embodiments of the disclosure. In one embodiment, the execution block611of processor600may include cache controller140forFIG. 1, for implementing techniques for supporting adaptive shared cache management functionality. In some embodiments, processor700may be the processing device100ofFIG. 1.

The term “registers” may refer to the on-board processor storage locations that are used as part of instructions to identify operands. In other words, registers may be those that are usable from the outside of the processor (from a programmer's perspective). However, the registers of an embodiment should not be limited in meaning to a particular type of circuit. Rather, a register of an embodiment is capable of storing and providing data, and performing the functions described herein. The registers described herein can be implemented by circuitry within a processor using any number of different techniques, such as dedicated physical registers, dynamically allocated physical registers using register renaming, combinations of dedicated and dynamically allocated physical registers, etc. In one embodiment, integer registers store 32 bit integer data. A register file of one embodiment also may contain an eight multimedia SIMD register for packed data.

For the discussions below, the registers are understood to be data registers designed to hold packed data, such as 64 bits wide MMX™ registers (also referred to as ‘mm’ registers in some instances) in microprocessors enabled with MMX™ technology from Intel Corporation of Santa Clara, Calif. These MMX™ registers, available in both integer and floating point forms, can operate with packed data elements that accompany SIMD and SSE instructions. Similarly, 128 bits wide XMM™ registers relating to SSE2, SSE3, SSE4, or beyond (referred to generically as “SSEx”) technology can also be used to hold such packed data operands. In one embodiment, in storing packed data and integer data, the registers do not need to differentiate between the two data types. In one embodiment, integer and floating point are either contained in the same register file or different register files. Furthermore, in one embodiment, floating point and integer data may be stored in different registers or the same registers.

Embodiments may be implemented in many different system types. Referring now toFIG. 7, shown is a block diagram illustrating a system700in which an embodiment of the disclosure may be used. As shown inFIG. 7, multiprocessor system700is a point-to-point interconnect system, and includes a first processor770and a second processor780coupled via a point-to-point interconnect750. While shown with only two processors770,780, it is to be understood that the scope of embodiments of the disclosure is not so limited. In other embodiments, one or more additional processors may be present in a given processor. In one embodiment, the multiprocessor system700may implement techniques for supporting adaptive shared cache management functionality as described herein.

Processors770and780are shown including integrated memory controller units772and782, respectively. Processor770also includes as part of its bus controller units point-to-point (P-P) interfaces776and778; similarly, second processor780includes P-P interfaces786and788. Processors770,780may exchange information via a point-to-point (P-P) interface750using P-P interface circuits778,788. As shown inFIG. 7, IMCs772and782couple the processors to respective memories, namely a memory732and a memory734, which may be portions of main memory locally attached to the respective processors.

Processors770,780may exchange information with a chipset790via individual P-P interfaces752,754using point to point interface circuits776,794,786,798. Chipset790may also exchange information with a high-performance graphics circuit738via a high-performance graphics interface739.

Chipset790may be coupled to a first bus716via an interface796. In one embodiment, first bus716may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the disclosure is not so limited.

As shown inFIG. 7, various I/O devices714may be coupled to first bus716, along with a bus bridge718which couples first bus716to a second bus720. In one embodiment, second bus720may be a low pin count (LPC) bus. Various devices may be coupled to second bus720including, for example, a keyboard and/or mouse722, communication devices727and a storage unit728such as a disk drive or other mass storage device which may include instructions/code and data730, in one embodiment. Further, an audio I/O724may be coupled to second bus720. Note that other architectures are possible. For example, instead of the point-to-point architecture ofFIG. 7, a system may implement a multi-drop bus or other such architecture.

Referring now toFIG. 8, shown is a block diagram of a system800in which one embodiment of the disclosure may operate. The system800may include one or more processors810,815, which are coupled to graphics memory controller hub (GMCH)820. The optional nature of additional processors815is denoted inFIG. 8with broken lines. In one embodiment, processors810,815implement techniques for supporting adaptive shared cache management functionality according to embodiments of the disclosure.

Each processor810,815may be some version of the circuit, integrated circuit, processor, and/or silicon integrated circuit as described above. However, it should be noted that it is unlikely that integrated graphics logic and integrated memory control units would exist in the processors810,815.FIG. 8illustrates that the GMCH820may be coupled to a memory840that may be, for example, a dynamic random access memory (DRAM). The DRAM may, for at least one embodiment, be associated with a non-volatile cache.

The GMCH820may be a chipset, or a portion of a chipset. The GMCH820may communicate with the processor(s)810,815and control interaction between the processor(s)810,815and memory840. The GMCH820may also act as an accelerated bus interface between the processor(s)810,815and other elements of the system800. For at least one embodiment, the GMCH820communicates with the processor(s)810,815via a multi-drop bus, such as a frontside bus (FSB)895.

Furthermore, GMCH820is coupled to a display845(such as a flat panel or touchscreen display). GMCH820may include an integrated graphics accelerator. GMCH820is further coupled to an input/output (I/O) controller hub (ICH)850, which may be used to couple various peripheral devices to system800. Shown for example in the embodiment ofFIG. 8is an external graphics device860, which may be a discrete graphics device, coupled to ICH850, along with another peripheral device870.

Alternatively, additional or different processors may also be present in the system800. For example, additional processor(s)815may include additional processors(s) that are the same as processor810, additional processor(s) that are heterogeneous or asymmetric to processor810, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processor. There can be a variety of differences between the processor(s)810,815in terms of a spectrum of metrics of merit including architectural, micro-architectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetry and heterogeneity amongst the processors810,815. For at least one embodiment, the various processors810,815may reside in the same die package.

Referring now toFIG. 9, shown is a block diagram of a system900in which an embodiment of the disclosure may operate.FIG. 9illustrates processors970,980. In one embodiment, processors970,980may techniques for supporting adaptive shared cache management functionality as described above. Processors970,980may include integrated memory and I/O control logic (“CL”)972and982, respectively and intercommunicate with each other via point-to-point interconnect950between point-to-point (P-P) interfaces978and988respectively. Processors970,980each communicate with chipset990via point-to-point interconnects952and954through the respective P-P interfaces976to994and986to998as shown. For at least one embodiment, the CL972,982may include integrated memory controller units. CLs972,982may include I/O control logic. As depicted, memories932,934coupled to CLs972,982and I/O devices914are also coupled to the control logic972,982. Legacy I/O devices915are coupled to the chipset990via interface996.

Embodiments may be implemented in many different system types.FIG. 10is a block diagram of a SoC1000in accordance with an embodiment of the disclosure. Dashed lined boxes are optional features on more advanced SoCs. InFIG. 10, an interconnect unit(s)1012is coupled to: an application processor1020which includes a set of one or more cores1002A-N and shared cache unit(s)1006; a system agent unit1010; a bus controller unit(s)1016; an integrated memory controller unit(s)1014; a set of one or more media processors1018which may include integrated graphics logic1008, an image processor1024for providing still and/or video camera functionality, an audio processor1026for providing hardware audio acceleration, and a video processor1028for providing video encode/decode acceleration; an static random access memory (SRAM) unit1030; a direct memory access (DMA) unit1032; and a display unit1040for coupling to one or more external displays. In one embodiment, a memory module may be included in the integrated memory controller unit(s)1014. In another embodiment, the memory module may be included in one or more other components of the SoC1000that may be used to access and/or control a memory. The application processor1020may include a PMU for implementing adaptive shared cache circuit145as described in embodiments herein.

The memory hierarchy includes one or more levels of cache within the cores, a set or one or more shared cache units1006, and external memory (not shown) coupled to the set of integrated memory controller units1014. The set of shared cache units1006may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof.

In some embodiments, one or more of the cores1002A-N are capable of multi-threading. The system agent1010includes those components coordinating and operating cores1002A-N. The system agent unit1010may include for example a power control unit (PCU) and a display unit. The PCU may be or include logic and components needed for regulating the power state of the cores1002A-N and the integrated graphics logic1008. The display unit is for driving one or more externally connected displays.

The cores1002A-N may be homogenous or heterogeneous in terms of architecture and/or instruction set. For example, some of the cores1002A-N may be in order while others are out-of-order. As another example, two or more of the cores1002A-N may be capable of execution the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set.

The application processor1020may be a general-purpose processor, such as a Core™ i3, i5, i7, 2 Duo and Quad, Xeon™, Itanium™, Atom™ or Quark™ processor, which are available from Intel™ Corporation, of Santa Clara, Calif. Alternatively, the application processor1020may be from another company, such as ARM Holdings™, Ltd, MIPS™, etc. The application processor1020may be a special-purpose processor, such as, for example, a network or communication processor, compression engine, graphics processor, co-processor, embedded processor, or the like. The application processor1020may be implemented on one or more chips. The application processor1020may be a part of and/or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.

FIG. 11is a block diagram of an embodiment of a system on-chip (SoC) design in accordance with the disclosure. As a specific illustrative example, SoC1100is included in user equipment (UE). In one embodiment, UE refers to any device to be used by an end-user to communicate, such as a hand-held phone, smartphone, tablet, ultra-thin notebook, notebook with broadband adapter, or any other similar communication device. Often a UE connects to a base station or node, which potentially corresponds in nature to a mobile station (MS) in a GSM network.

Here, SOC1100includes 2 cores—1106and1107. Cores1106and1107may conform to an Instruction Set Architecture, such as an Intel® Architecture Core™-based processor, an Advanced Micro Devices, Inc. (AMD) processor, a MIPS-based processor, an ARM-based processor design, or a customer thereof, as well as their licensees or adopters. Cores1106and1107are coupled to cache control1108that is associated with bus interface unit1109and L2 cache1110to communicate with other parts of system1100. Interconnect1110includes an on-chip interconnect, such as an IOSF, AMBA, or other interconnect discussed above, which potentially implements one or more aspects of the described disclosure. In one embodiment, cores1106,1107may implement techniques for supporting adaptive shared cache management functionality as described in embodiments herein.

Interconnect1110provides communication channels to the other components, such as a Subscriber Identity Module (SIM)1130to interface with a SIM card, a boot ROM1140to hold boot code for execution by cores1106and1107to initialize and boot SoC1100, a SDRAM controller1140to interface with external memory (e.g. DRAM1160), a flash controller1145to interface with non-volatile memory (e.g. Flash1165), a peripheral control1150(e.g. Serial Peripheral Interface) to interface with peripherals, video codecs1120and Video interface1125to display and receive input (e.g. touch enabled input), GPU1115to perform graphics related computations, etc. Any of these interfaces may incorporate aspects of the disclosure described herein. In addition, the system1100illustrates peripherals for communication, such as a Bluetooth module1170, 3G modem1175, GPS1180, and Wi-Fi1185.

The computer system1200includes a processing device1202, a main memory1204(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory1206(e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device1218, which communicate with each other via a bus1230.

Processing device1202represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computer (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device1202may also be one or more special-purpose processing devices such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. In one embodiment, processing device1202may include one or more processing cores. The processing device1202is configured to execute the processing logic1226for performing the operations and steps discussed herein. In one embodiment, processing device1202is the same as processor architecture100described with respect toFIG. 1that implements techniques for supporting adaptive shared cache management functionality as described herein with embodiments of the disclosure.

The computer system1200may further include a network interface device1208communicably coupled to a network1220. The computer system1200also may include a video display unit1210(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device1212(e.g., a keyboard), a cursor control device1214(e.g., a mouse), and a signal generation device1216(e.g., a speaker). Furthermore, computer system1200may include a graphics processing unit1222, a video processing unit1228, and an audio processing unit1232.

The data storage device1218may include a non-transitory machine-accessible storage medium1224on which is stored software1226implementing any one or more of the methodologies of functions described herein, such as implementing adaptive shared cache circuit145on threads in a processing device, such as processing device100ofFIG. 1, as described above. The software1226may also reside, completely or at least partially, within the main memory1204as instructions1226and/or within the processing device1202as processing logic1226during execution thereof by the computer system1200; the main memory1204and the processing device1202also constituting machine-accessible storage media.

The following examples pertain to further embodiments.

Example 1 includes a plurality of processing cores; and a cache controller, operatively coupled to the processing cores, to: determine a cache line to evict from a shared cache; select an inactive processing core of a plurality of processing cores associated with the shared cache; notify a private cache of the inactive processing core of an identifier of a cache line associated with the shared cache; and forward the cache line from the shared cache to the private cache.

Example 2 includes the processing device of example 1, wherein the cache controller is to identify the cache line based on a counter associated with the shared cache.

Example 3 includes the processing device of example 2, wherein the counter indicates that the identified cache line is a least-recently-used (LRU) memory space of the shared cache.

Example 4 includes the processing device of example 1, wherein the cache controller is further to: receive an access request with respect to the cache line; and forward the memory request to the private cache of the inactive processing core to retrieve the cache line.

Example 5 includes the processing device of example 1, wherein the cache controller is further to provide a message to initiate a prefetch of the cache line by the private cache of the inactive processing core.

Example 6 includes the processing device of example 1, wherein the request comprises the identifier of the cache line.

Example 7 includes the processing device of example 1, wherein the cache controller is further to trigger an eviction of the cache line in the private cache of the inactive processing core to main memory.

Example 8 includes the processing device of example 1, further comprising a memory device to implement the shared cache, wherein the shared cache is shared by the plurality of processing cores.

Example 9 includes a method comprising: determining, by a processing device, a cache line to evict from a shared cache; selecting, by the processing device, an inactive processing core of a plurality of processing cores associated with the shared cache; notifying, by the processing device, a private cache of the inactive processing core of an identifier of a cache line associated with the shared cache; and forwarding, by the processing device, the cache line from the shared cache to the private cache.

Example 10 includes the method of example 9, further comprising identifying the cache line based on a counter associated with the shared cache.

Example 11 includes the method of example 10, wherein the counter indicates that the identified cache line is a least-recently-used (LRU) memory space of the shared cache.

Example 12 includes the method of example 9, further comprising: receiving an access request with respect to the cache line; and forwarding the memory request to the private cache of the inactive processing core to retrieve the cache line.

Example 13 includes the method of example 9, further comprising providing a message to initiate a prefetch of the cache line by the private cache of the inactive processing core.

Example 14 includes the method of example 9, wherein the request comprises the identifier of the cache line.

Example 15 includes the method of example 9, further comprising triggering an eviction of the cache line in the private cache of the inactive processing core to main memory.

Example 16 includes a system comprising: a shared cache to store a plurality of cache lines; and a processing device, operatively coupled to the shared cache, to: determine a cache line to evict from a shared cache; select an inactive processing core of a plurality of processing cores associated with the shared cache; notify a private cache of the inactive processing core of an identifier of a cache line associated with the shared cache; and forward the cache line from the shared cache to the private cache.

Example 17 includes the system of example 16, wherein the processing device is further to identify the cache line based on a counter associated with the shared cache.

Example 18 includes the system of example 17, wherein the counter indicates that the identified cache line is a least-recently-used (LRU) memory space of the shared cache.

Example 19 includes the system of example 16, wherein the processing device is further to provide a message to initiate a prefetch of the cache line by the private cache of the inactive processing core.

Example 20 includes the system of example 16, wherein the processing device is further to: receive an access request with respect to the cache line; and forward the memory request to the private cache of the inactive processing core to retrieve the cache line.

Example 21 includes the system of example 16, wherein the processing device is further to provide a message to initiate a prefetch of the cache line by the private cache of the inactive processing core.

Example 22 includes the system of example 16, wherein the request comprises the identifier of the cache line.

Example 23 includes the system of example 16, wherein the processing device is further to trigger an eviction of the cache line in the private cache of the inactive processing core to main memory.

Example 24 includes a non-transitory computer-readable medium comprising instructions that, when executed by a processing device, cause the processing device to: determine, by the processing device, a cache line to evict from a shared cache; select an inactive processing core of a plurality of processing cores associated with the shared cache; notify a private cache of the inactive processing core of an identifier of a cache line associated with the shared cache; and forward the cache line from the shared cache to install in the private cache.

Example 25 includes the non-transitory computer-readable medium of example 24, wherein the processing device is further to identify the cache line based on a counter associated with the shared cache.

Example 26 includes the non-transitory computer-readable medium of example 25, wherein the counter indicates that the identified cache line is a least-recently-used (LRU) memory space of the shared cache.

Example 27 includes the non-transitory computer-readable medium of example 24, wherein the processing device is further to provide a message to initiate a prefetch of the cache line by the private cache of the inactive processing core.

Example 28 includes the non-transitory computer-readable medium of example 24, wherein the processing device is further to: receive an access request with respect to the cache line; and forward the memory request to the private cache of the inactive processing core to retrieve the cache line.

Example 29 includes the non-transitory computer-readable medium of example 24, wherein the processing device is further to provide a message to initiate a prefetch of the cache line by the private cache of the inactive processing core.

Example 30 includes the non-transitory computer-readable medium of example 24, wherein the request comprises the identifier of the cache line.

Example 31 includes the non-transitory computer-readable medium of example 24, wherein the processing device is further to trigger an eviction of the cache line in the private cache of the inactive processing core to main memory.

Example 32 includes a non-transitory, computer-readable storage medium including instructions that, when executed by a processor, cause the processor to perform the method of examples 9-15.

Example 33 includes an apparatus comprising: a plurality of functional units of a processor; means for determining a cache line to evict from a shared cache; means for selecting an inactive processing core of a plurality of processing cores associated with the shared cache; means for notifying a private cache of the inactive processing core of an identifier of a cache line associated with the shared cache; and means for forwarding the cache line from the shared cache to install in the private cache.

Example 34 includes the apparatus of example 33, further comprising the subject matter of any of examples 1-8 and 16-23.

Example 35 includes a system comprising: a memory device and a processor comprising a memory controller unit, wherein the processor is configured to perform the method of any of examples 9-15.

Example 36 includes the system of example 35, further comprising the subject matter of any of examples 1-8 and 16-23.

While the disclosure has been described respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations there from. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this disclosure.

Furthermore, use of the phrases ‘to,’ ‘capable of/to,’ and/or ‘operable to,’ in one embodiment, refers to some apparatus, logic, hardware, and/or element designed in such a way to enable use of the apparatus, logic, hardware, and/or element in a specified manner. Note as above that use of, capable to, or operable to, in one embodiment, refers to the latent state of an apparatus, logic, hardware, and/or element, where the apparatus, logic, hardware, and/or element is not operating but is designed in such a manner to enable use of an apparatus in a specified manner.