MANAGING CACHED DATA USED BY PROCESSING-IN-MEMORY INSTRUCTIONS

[0001] This application is a continuation in part of U.S. patent application Ser. No. 17/123,270, filed Dec. 16, 2020, the entirety of which is hereby incorporated by reference.

[0002] Computing systems often include a number of processing resources, such as processors or processor cores, which can retrieve instructions, execute instructions, and store the results of executed instructions to memory. A processing resource can include a number of functional units such as arithmetic logic units (ALUs), floating point units (FPUs), and combinatorial logic blocks, among others. Typically, such functional units are local to the processing resources. That is, functional units tend to be implemented as part of a processor and are separate from memory devices in which data to be operated upon is retrieved and data forming the results of operations is stored. Such data can be accessed via a bus between the processing resources and memory. To reduce the amount of accesses to fetch or store data in memory—specifically in main memory—computing systems employ a cache hierarchy that temporarily stores recently accessed or modified data in a memory device that is quicker and more power efficient to access than main memory. Such cache memory is sometimes referred to as being ‘closer’ to the processor or processor core.

[0003] Processing performance can be improved by offloading operations that would normally be executed in the functional units to a processing-in-memory (PIM) device. PIM refers to an integration of compute and memory for execution of instructions that would otherwise be executed by a computer system's primary processor or processor cores. In some implementations, PIM devices incorporate both memory and functional units in a single component or chip. Although PIM is often implemented as processing that is incorporated ‘in’ memory, this specification does not limit PIM so. Instead, PIM may also include so-called processing-near-memory implementations and other accelerator architectures. That is, the term ‘PIM’ as used in this specification refers to any integration—whether in a single chip or separate chips—of compute and memory for execution of instructions that would otherwise be executed by a computer system's primary processor or processor core. In this way, instructions executed in a PIM architecture are executed ‘closer’ to the memory accessed in executing the instruction. In this way, a PIM device can save time by reducing or eliminating external communications and can also conserve power that would otherwise be necessary to process memory communications between the processor and the memory.

[0004] Some portions of phases of applications may be well-suited for offloading to a PIM device. Some applications during execution, for example, have phases of low or no temporal data reuse. During such phases, there are frequent misses in the cache hierarchy and frequency fetching of data from main memory. In addition, such phases can also exhibit low computational intensity (in terms of FLOPs per byte of data accessed, for example). During such phases, energy efficiency and performance drops because data movement is high and the phases are memory bound. A phase is memory bound in that the rate which the instructions of the phase are progress is limited by the amount of memory available and/or speed of memory access. Accordingly, these phases are particularly well-suited for offloading to a PIM device.

[0009] Processing-in-Memory (PIM) architectures support offloading instructions for execution in or near memory, such that bandwidth on the data link between the processor and the memory is conserved and power consumption of the processor is reduced. However, data that is to be accessed for execution of a PIM instruction must remain coherent throughout a memory hierarchy, including the various levels of cache, to ensure functional correctness of PIM code.

[0010] To enable computation by a PIM device, instructions offloaded to the PIM device must use, or operate on, the most recent version of data. However, the most recent version of the data to be used in execution of a PIM instruction could be present in the CPU caches as a result of being accessed and updated by non-PIM instructions, preceding the PIM code execution. To that end, in some PIM architectures, offloads of PIM instructions are carried out in a manner to ensure that data that is resident in a cache and is to be used in execution of a PIM instruction is flushed from the cache to memory.

[0011] In such an architecture, PIM instructions touching memory, such as PIM Load and PIM Store instructions, undergo address translation in the core as regular load or store instructions. However, unlike regular load or store instructions, once the address translation is completed, the instructions are marked as retired without fetching data from the cache hierarchy. That is, PIM instructions are immediately considered executed by the PIM device once address translation is completed without fetching operand data for the instructions. At retire time, PIM instructions are placed in a PIM queue and are eventually dispatched to the PIM device for execution. As part of the dispatch flow, PIM instructions access the System Probe Filter (SPF) to perform a lookup and determine whether data to be used in execution of the instruction is present in a cache. If the SPF lookup results in a hit (meaning the data is present in a cache), a probe request is sent to the corresponding cache-levels to invalidate or flush the data to memory.

[0012] If the data to be used by a PIM read instruction is in a cache and the data is marked dirty, a PIM read request will wait to be dispatched until the data is flushed from the cache to memory. Such a wait limits the dispatch bandwidth of PIM read instructions to PIM devices. In cases in which the data to be used by a PIM instruction is clean (regardless of PIM instruction type), the PIM instruction is forwarded to the PIM device while the data is invalidated in the cache. This invalidation can safely occur because memory has the same copy as the data in the cache or because the instruction is a PIM write request that will overwrite the copy of the data that is resident in the cache.

[0013] Because a probe response from a cache can take several cycles, PIM instructions can remain in the PIM queues for relatively long periods of time, thereby limiting the PIM instruction dispatch bandwidth. Moreover, PIM instructions cannot be forwarded to the PIM device out of order. The original dispatch order from the CPU core must match the program order. This order has to be preserved all the way to the PIM device. Therefore, if a PIM instruction that reads or writes memory has to wait in the PIM queues for a probe response that needs to flush out PIM data from the caches, all younger PIM requests from the same thread need to wait as well.

[0014] To that end, various implementations and apparatus for early or ‘eagerly’ invalidating or flushing PIM data from caches are disclosed in this specification. In some implementations, a system-on-chip (SOC) is provided for eagerly invalidating and flushing cached data used by PIM instructions. The SOC includes one or more processor cores, one or more caches, and an I/O (input/output) die. The I/O die includes logic to receive a cache probe request, where the cache probe request includes a physical memory address associated with a PIM instruction and the PIM instruction is to be offloaded to a PIM device for execution. The I/O die logic is also configured to issue, based on the physical memory address, a cache probe to one or more of the caches prior to receiving the PIM instruction for dispatch to the PIM device. In some implementations, the cache probe is issued to one or more caches to invalidate or flush data associated with the physical memory address.

[0015] In some implementations, the I/O die includes a coherency synchronizer that synchronizes cache states for a plurality of processor cores. The coherency synchronizer includes logic to receive the PIM instruction after the PIM instruction is dispatched by a processor core. The coherency synchronizer also includes logic to dispatch the PIM instruction to the PIM device when probe responses to the cache probe have been received from the one or more caches.

[0016] In some implementations, a processor core of the SOC is configured to resolve the physical memory address associated with the PIM instruction and dispatch a cache probe request based on the resolved physical memory address to the coherency synchronizer. The cache coherency synchronizer issues the cache probe to the one or more caches before the processor core completes the PIM instruction.

[0017] In some implementations, a processor core of the SOC is also configured to resolve the physical memory address, wherein the physical memory address is specified in a cache control instruction associated with the PIM instruction. The processor core is also configured to dispatch a cache probe request based on the physical memory address to the coherency synchronizer. The cache coherency synchronizer issues the cache probe to the one or more caches before the processor core completes the PIM instruction.

[0018] In additional implementations, a SOC is configured for eager invalidation and flushing of PIM data from cache according to various implementations of the present disclosure and includes one or more processor cores, one or more caches, and an I/O die. The I/O die includes logic that, based on at least one first PIM instruction specifying a first physical memory address, is configured to speculate a second physical memory address. The logic of the I/O die is also configured to issue a cache probe to one or more caches before encountering a second PIM instruction that specifies the second physical memory address. In some implementations, the second physical memory address is speculated based on a pattern of memory accesses of prior PIM instructions.

[0019] In some implementations, the I/O die of the SOC includes a coherency synchronize configured to: receive the second PIM instruction after the second PIM instruction is dispatched by a processor core; determine, upon receipt of the second PIM instruction, whether probe responses to the cache probe have been received from the one or more caches; and dispatch the second PIM instruction to the PIM device when probe responses to the cache probe have been received from the one or more caches.

[0020] Methods of eagerly invalidating or flushing PIM data from caches are also disclosed in this specification. Such eager invalidation or flushing of PIM data includes, in some implementations, receiving a cache probe request, where the cache probe request includes a physical memory address associated with a PIM instruction and the PIM instruction is to be offloaded to a PIM device for execution. The eager invalidation or flushing of PIM data also includes issuing a cache probe to one or more caches based on the physical memory address prior to receiving the PIM instruction for dispatch to the PIM device. The cache probe is issued to one or more caches to invalidate or flush data associated with the physical memory address.

[0021] In some implementations, eagerly invalidating or flushing PIM data also includes receiving, at a coherency synchronizer, the PIM instruction after the PIM instruction is dispatched by a processor core; determining, upon receipt of the PIM instruction, whether probe responses to the cache probe have been received from the one or more caches; and dispatching the PIM instruction to the PIM device when probe responses to the cache probe have been received from the one or more caches. In such implementations, the coherency synchronizer synchronizes cache states for a plurality of processor cores.

[0022] In some implementations, eagerly invalidating or flushing PIM data also includes resolving, by a processor core, the physical memory address, where the physical memory address is specified in the PIM instruction and dispatching, by the processor core to a coherency synchronizer, a cache probe request based on the resolved physical memory address. In such implementations, issuing the cache probe to one or more caches includes dispatching, by the coherency synchronizer to the one or more caches, the cache probe before the processor core completes the PIM instruction.

[0023] In some implementations, eagerly invalidating or flushing PIM data also includes resolving, by a processor core, the physical memory address, where the physical memory address is specified in a cache control instruction associated with the PIM instruction and dispatching, by the processor core to a coherency synchronizer, a cache probe request based on the physical memory address. In such implementations, issuing the cache probe to one or more caches includes dispatching, by the coherency synchronizer to the one or more caches, the cache probe before the processor core completes the PIM instruction.

[0024] Additional methods of eagerly invalidating and flushing cached data used by PIM are disclosed. Such a method includes, based on at least one first PIM instruction specifying a first physical memory address, speculating a second physical memory address. Such a method also includes issuing a cache probe to one or more caches before encountering a second PIM instruction that specifies the second physical memory address. In such implementations, the cache probe is issued to one or more caches to invalidate or flush data associated with the second physical memory address. In such implementations, the second physical memory address is speculated based on a pattern of memory accesses of prior PIM instructions.

[0025] In some variations of the aforementioned method, eagerly invalidating and flushing cached data used by PIM also includes receiving, at a coherency synchronizer, the second PIM instruction after the second PIM instruction is dispatched by a processor core; determining, upon receipt of the second PIM instruction, whether probe responses to the cache probe have been received from the one or more caches; and dispatching the second PIM instruction to the PIM device when probe responses to the cache probe have been received from the one or more caches. In such a method, the coherency synchronizer synchronizes cache states for a plurality of processor cores.

[0026] For further explanation of the various implementations of the apparatus, products, and methods set forth, FIG. 1 sets for a block diagram illustrating an example system 100 that supports execution of PIM instructions. In the example of FIG. 1, the system 100 includes a multicore processor 101 that includes multiple core complexes 102, 104 that include a cluster of cores (e.g., 2 or more cores sharing a last-level cache or interface). For example, the processor 101 can be implemented in a system-on-chip (SoC) architecture. In the example depicted in FIG. 1, each core complex 102, 104 includes multiple processor cores 106, 108, 110, 112 (e.g., central processing unit (CPU) cores, graphical processing unit (GPU) cores, etc.) respectively coupled to second-level (L2) caches 114, 116, 118, 120. Further, each of the processor cores 106, 108, 110, 112 includes respective primary (L1) caches 122, 124, 126, 128. Each of the processor cores 106, 108, 110, 112 includes various components of a processor pipeline (not depicted) such as an instruction fetch, decode, and dispatch pipeline, prefetch input queues, schedulers, load/store queues, lookaside buffers, reorder buffers, and retire queues as well as various arithmetic logic units (ALUs) and register files.

[0027] The configuration of the example system 100 depicted in FIG. 1 is presented for the purpose of explanation. Readers will appreciate that, while four processor cores 106, 108, 110, 112 are depicted in FIG. 1, the processor 101 can include more or fewer processor cores than depicted, as well as more or fewer core complexes, as well as more or fewer caches.

[0028] In the example depicted in in FIG. 1, each core complex 102, 104 includes a third level (L3) cache 130, 132 that serves as an interconnect cache, or last level cache (LLC), that connects all of the L2 caches of a particular core complex. In some examples, the processor 101 is configured to execute multithreaded applications using the multiple processor cores 106, 108, 110, 112. In these examples, a modification of data in a cache in one core complex 102 affects the validity of data cached in another core complex 104. To enforce cache coherency, the processor 101 includes a coherency synchronizer 134 coupled to each L3 cache 130, 132 of the core complexes 102, 104. In these examples, the coherency synchronizer 134 initiates cache operations, for example, by transmitting cache probes to invalidate or flush data contained in cache entries of any L1, L2, or L3 cache present in the processor 101.

[0029] Each L1, L2, and L3 cache includes cache logic that, in response to a processor request, determines whether data associated with a requested operation is present in a cache entry of the cache. If the data is present (a ‘cache hit’), the processor request is fulfilled using the data present in the cache entry. If the data is not present (a ‘cache miss’), the request is forwarded to the next-level cache until a cache miss is detected in the LLC. In response to a cache miss in the LLC, the cache is forwarded to a memory controller 136 of the processor 101 to fulfill the request using data stored in main memory (e.g., memory device 138). In one example, the processor requests are input/output (I/O) operations, such as read/write requests, directed to a memory location in the memory device 138.

[0030] Each of the processor cores 106, 108, 110, 112 executes machine language code created by a compiler from an application that executes on the processor 101. For example, the application can be a single-threaded or multithreaded application. The processor cores implement an instruction set architecture (ISA) utilized by the compiler system for generating the machine language code. In one example, the ISA for the processor 101 is the x86-64 instruction set with support for advanced vector extension such as AVX-256.

[0031] In accordance with various implementations of the present disclosure, the processor 101 implements an extended ISA with three opcodes for offloading operations to PIM device as well an architected register file for the PIM device. In the extended ISA, a remote_load instruction opcode loads data of a memory operand from main memory into a local register of the PIM device, while a remote_store instruction opcode writes data from a local register of the PIM device to a memory operand in main memory. A remote_op instruction opcode in the extended ISA can represent any arithmetic or logical operation supported by the PIM device's fixed function architecture. None of the operations modifies control flow and thus the PIM instructions are executed in sequence. The remote_op instruction source operands can be (a) a memory address (specified in the same way as in the baseline ISA), (b) an architectural register (from the CPU standard ISA), or (c) a PIM register implemented in the PIM device. In some implementations, a PIM instruction destination operand can only be a PIM register. The PIM registers are architected registers within the extended ISA that represent registers local to the PIM fixed function logic and are allocated by the compiler. The PIM registers are virtual in that they have no physical storage in the processor core and are used to support data dependencies between PIM instructions and to track PIM register usage at the memory controller 136 when the PIM instructions are sent to the PIM fixed function module 146.

[0032] In some implementations, the remote_load instruction includes a destination operand that is an PIM register, a source operand that is a memory address, and another source operand that is an architectural register that is used to generate a memory address. The remote_load instruction indicates that the PIM device should load data from the memory location identified by the memory address into the PIM register.

[0033] In some implementations, the remote_store instruction includes a destination operand that is a memory address, a source operand that is an PIM register and another source operand that is an architectural register used to generate the memory address. The remote_store instruction indicates that the PIM device should store data from the PIM register to memory location identified by the memory address.

[0034] In some implementations, the remote_op instruction includes a destination operand that is an PIM register and source operands for a computation, where the source operands can be architectural registers (carrying values from prior non-offloaded computations), PIM registers or a memory address (generated from an architectural register also specified in the remote_op instruction). The remote_op instruction indicates that fixed function logic in the PIM device should perform the computation and place the result in the PIM register indicated by the destination operand.

[0035] In some implementations, the PIM instructions are generated by the compiler at application compile time using the extended ISA. In one example, the compiler identifies PIM instructions in source code based on indications in application source code provided by the programmer, for example, using an application programming interface (API) for offloading. In another example, the compiler identifies instructions for offloading to a PIM device based on a determination that the instructions are suitable for offloading. The PIM instructions can be identified as a region of interest (ROI) in the source code. Each dynamic instance of an ROI in the source code can be identified as an PIM transaction that includes one or more PIM instructions. For example, a PIM transaction can include remote_load instruction, one or more remote_op instructions, and a remote_store instruction. A PIM transaction can be a loop iteration or a subroutine or a subset of subroutine's body. The PIM transaction is a sequential piece of code and does not include any control flow changing instructions. In some examples, special instructions can mark the beginning and end of each PIM transaction.

[0036] In some implementations, a PIM instruction is fetched, decoded, and dispatched (e.g., by the front-end pipeline of the core), as would be performed for any typical non-PIM instruction. After the PIM instruction is dispatched and once the PIM instruction has been picked by a scheduler, core resources are used to generate virtual and/or physical addresses for any memory locations identified in the PIM instruction (e.g., in remote_load, remote_store and remote_op instructions that have a memory operand) and any values consumed by PIM instructions from core registers (e.g., computed from non-PIM instructions). After the virtual and/or physical addresses have been generated and the values from core registers are available, a PIM instruction is ready to retire. Even though PIM instructions are picked by a scheduler, these instructions do not execute in the core's ALUs (vector or scalar, integer or floating point), neither do they modify machine state when issued by the core, including architected registers and flags as defined in the core's standard ISA. PIM instructions are ready to retire as soon as they have completed the operations (address generation and/or reading values computed by non-PIM instructions) mentioned above without violating memory ordering. In the event of pipeline flushing (e.g., due to branch mispredictions, load-store forwarding data dependence violations, interrupts, traps, etc.), the PIM instructions can be flushed like conventional instructions because they occupy instruction window entries like non-PIM instructions. Further, because remote_op instructions do not execute on the core's ALUs, no arithmetic error traps are detected for them. However, other traps (e.g., for virtual or physical address generation, instruction breakpoints, etc.) generated by PIM instructions are detected and served inside the core pipeline with the same mechanisms used for non-PIM instructions.

[0037] Once the PIM instructions retire, the generated memory addresses and values of any core register operands are included in a PIM request generated for the PIM instruction. The PIM request includes the PIM instruction and the PIM register as well as any generated memory address or register values need to complete the PIM instruction and store the result in the PIM register. In some implementations, a PIM request first-in-first-out (FIFO) queue for the PIM requests is utilized to maintain programmatic sequence for the instructions as the PIM instructions retire. In one example, the PIM instruction is retired only when the end of a PIM transaction is reached in the PIM request FIFO. There can be one PIM request FIFO per thread if the core supports multithreading. Each PIM request is issued to the PIM device in program order by the core at retire time to be executed in the same program order remotely in the PIM device.

[0038] In some examples, after a PIM request is issued by a processor core 106, 108, 110, 112, the PIM request is received by the coherency synchronizer 134. The coherency synchronizer 134 performs cache operation on the various caches of the core complexes 102, 104 to ensure that any cache entries for virtual and/or physical addresses identified in the PIM request remain coherent. For example, when a PIM request includes as an operand a virtual and/or physical address, the coherency synchronizer 134 performs a cache probe to identify cache entries in the L1, L2, and L3 caches of the core complex that contain cache entries for the virtual and/or physical addresses identified in the PIM request. If the identified cache entry contains clean data, the cache entry is invalidated. If the identified cache entry contains dirty data, the data in the cache entry is flushed to main memory (i.e., the memory device). In some examples, cache entries corresponding to virtual and/or physical addresses identified in the PIM request issued by a particular core in a core complex can be invalidated/flushed before reaching the coherency synchronizer 134, such that the coherency synchronizer 134 performs the cache probe only on other core complexes in the system 100. In other examples, the coherency synchronizer 134 receives the PIM request directly and performs the cache probe on all core complexes in the system 100. A memory fence can be employed to ensure that younger non-PIM instructions in the instruction queue do not access any cache entries for virtual and/or physical addresses identified in the PIM request(s) until those cache entries have been invalidated or flushed. In this way, the younger non-PIM instructions are prevented from accessing stale cache data and must instead retrieve the data from main memory (which may have been modified by a prior PIM request). After the appropriate cache operations have completed, the PIM request is transmitted to the memory controller 136 for offloading to the PIM device. The operation of the coherency synchronizer will be described in greater detail below.

[0039] In some implementations, the memory controller 136 receives the PIM requests, which can be configured as read or write requests with a flag that indicates the request is a PIM request. In these implementations, the memory controller 136 decodes the request to determine that the request is a PIM request and identifies the PIM instruction as well as operands for completing the PIM request. The memory controller 136 identifies the requested operation via a pointer to a command buffer located in the PIM device from the PIM request. The memory controller 136 breaks the PIM request into one or more commands that are transmitted to the PIM device.

[0040] In the example depicted in FIG. 1, the processor 101 is coupled to a memory device 138 that includes one or more memory arrays 142 for storing data. In some examples, the memory device 138 is a stacked dynamic random-access memory (DRAM) device that includes multiple memory dies stacked on a memory interface logic die that interface with the processor 101. For example, the memory device 138 can be a high bandwidth memory (HBM) module or a hybrid memory cube (HMC) module. In other examples, the memory device 138 can be an in-line memory module such as a dual in-line memory module (DIMM) that includes memory interface logic. The memory controller 136 issues commands to the memory logic 140 of the memory device 138, such as read requests, write requests, and other memory operations. In some implementation, commands transmitted to the memory device 138 by the memory controller 136 can be flagged as PIM commands.

[0041] In the example of FIG. 1, the memory device 138 implements a PIM device in that the memory logic 140 is designed to perform memory operations and a set of non-memory operations or functions (e.g., arithmetic and logical operations) within the memory device 138. In some implementations, the memory device 138 includes a separate register file 144 that can be used to provide operands to operate on by the functions.

[0042] In implementations where the PIM device is included as a component of the memory device 138, such as that of FIG. 1, the memory device 138 receives PIM instructions from the memory controller 136. In the example depicted in FIG. 1, the memory controller includes memory logic 140 that is coupled to a fixed function module 146 for implementing fixed functions identified in a PIM request. The fixed function module 146 can include a command buffer that is populated with the commands to be executed by the fixed function module 146. In some implementations, the opcode of each PIM instruction includes an embedded pointer to the command for the operation (load, store, add, subtract, multiply, increment, etc.) that is too be performed in the PIM device. When a PIM request is generated from a PIM instruction, this pointer is also included in the PIM request. In these implementations, when generating the commands, the memory controller uses the pointer in the PIM request to identify the location in the command buffer of the PIM device that includes the actual command for the operation.

[0043] Consider an example where the memory device implements a PIM device and, at compile time, the compiler system allocates a register r1 in the register file 144 and issues a multiply instruction to the fixed function module 146. In this simplified example, consider that the core 106 receives the following instructions:

• • [0044] pimLd r1, [5000];
  • [0045] pimOp r1, r1, 10;
  • [0046] pimSt [6000], r1;

[0047] where pimLd is a remote_load instruction, pimOp is a remote_op instruction, and pimSt is a remote_store instruction. The core generates PIM requests that are transmitted to the memory controller, as previous discussed. The memory controller 136 receives a sequence of PIM requests (received in the same program order indicated in the original machine code). In this example, the memory controller 136 receives a first PIM request that includes a load operation with a destination operand that is register r1, a source operand that is physical memory address 5000 in a memory array 142 and a pointer to the load instruction in the fixed function module 146. The memory controller 136 transmits one or more commands to the memory logic 140 for reading the address 5000 and loading the data into register r1 in the register file 144. The memory controller 136 then receives a second PIM request that includes a remote execution instruction with a destination operand that is register r1, a source operand that is register r1, and a source operand that is a scalar value (e.g., 10) obtained from the PIM request, as well as a pointer to the multiply instruction in the fixed function module 146. The memory controller 136 transmits one or more commands to the memory logic 140 for executing the multiply instruction in the fixed function module 146, where an ALU of the memory logic 140 is used to multiply the data in r1 by 10, and the result is written to register r1. The memory controller 136 then receives a third PIM request that is a store operation with a destination operand that is physical memory address 6000 in a memory array 142 a source operand that is register r1. The memory controller 136 transmits one or more commands to the memory logic 140 for storing the data in register r1 in a memory location identified by the physical memory address 6000.

[0048] In some examples, the coherency synchronizer 134 and memory controller 136 can be implemented on an I/O die 150 that is distinct from dies 154, 156 implementing the core complexes 102, 104. The I/O die 150 can be coupled through one or more channels to a memory interface die (not shown) that includes the memory logic 140 and fixed function module 146. One or more memory components each including a memory array 142 can be stacked on top of the memory interface die and coupled to the memory interface die using through-silicon vias. The I/O die 150 can be coupled to the core complex dies 154, 156 through an on-chip fabric.

[0049] The system of FIG. 1 may be configured to eagerly invalidate and flush PIM data from caches in accordance with various implementations of the present disclosure. For example, the coherency synchronizer 134 of the I/O die 150 of FIG. 1 is configured to receive a cache probe request. The cache probe request includes a physical memory address associated with a PIM instruction that is to be offloaded to the PIM device implemented in the memory device 138 for execution. The coherency synchronizer 134, based on the physical memory address of the PIM instruction, issues a cache probe to one or more of the caches 130, 132, 114, 116, 118, 120, 122, 124, 126, 128 prior to receiving the PIM instruction for dispatch to the PIM device. That is, the coherency synchronizer 134 initiates either a flush or invalidation of PIM data from the caches before the coherency synchronizer even receives the PIM instruction itself. In this way, the PIM instruction need not wait in a queue until the entire time the cache probe is propagated through the cache system. Instead, the cache probe begins propagation well before the PIM instruction arrives.

[0050] The system of FIG. 1 may also be configured to eagerly invalidate and flush PIM data from caches in other manners. For example, in the system of FIG. 1 the coherency synchronizer 134, based upon a first PIM instruction that specifies a first physical memory address, can speculate a physical memory address for a not-yet-received and possibly never-to-be-received PIM instruction. Then, in a completely speculative fashion, the coherency synchronizer 134 can issue a cache probe to one or more caches based on the second physical memory address. That is, even before encountering a PIM instruction that specifies the second physical memory address, the coherency synchronizer can preemptively and speculatively initiate a cache probe to flush PIM data from or invalidate PIM resident in the caches 114, 116, 118, 120, 130 132, 122, 124, 126, 128. The speculation of the memory address can be based on a previous or a pattern of previous PIM instructions or addresses related to those PIM instructions.

[0051] While the system of FIG. 1 sets forth an example architecture that supports PIM execution in which PIM is supported in a memory device itself, as noted above, PIM may be implemented in a variety of different manners. For further explanation, therefore, FIG. 2 sets for a block diagram illustrating another example system 200 that supports execution of PIM instructions in which the PIM device is implemented as an accelerator 238 coupled to a memory device 250.

[0052] The accelerator 238 is used by the processor 101 to remotely execute PIM instructions. For example, the PIM instructions can be loop iterations, a subroutine, a subset of subroutine's body, or other sequential piece of code as discussed above. In these implementations, the accelerator 238 behaves similarly to the memory device 138 that is configured as a PIM device, as discussed above, in that the extended ISA implemented by the processor 101 may be utilized for offloading instructions to the accelerator 238.

[0053] The accelerator 238 includes accelerator logic such as processing resources designed to perform memory operations (load/store) and non-memory operations (e.g., arithmetic and logical operations) within the accelerator 238. For example, the accelerator 238 can load data from the memory device 250, perform computations on data, and store data in the memory device 250. In some implementations, the accelerator 238 is designed to implement a set of fixed functions, which can be executed by the accelerator logic 240. In these implementations, the accelerator 238 includes a register file 244 used to provide the operands needed to execute the fixed functions. Registers in the register file 244 can be targeted in PIM instructions as source or destination operands using the extended ISA discussed above.

[0054] The accelerator 238 receives PIM instructions generated from the PIM requests from the memory controller 136 of the processor 101. In the example depicted in FIG. 2, the accelerator logic 240 is coupled to a PIM fixed function module 246 for implementing a set of fixed functions identified in a PIM request. The fixed function module 246 can include a command buffer that stores the actual commands to be executed by the fixed function module 246. The command buffer is populated by the operating system when an application thread including the PIM instructions is launched. The processing of PIM instructions is similar to the processing of PIM instructions performed by the memory device 138 as discussed above, except that the memory array is not local to the accelerator 238 as it is in the memory device 138.

[0055] The system of FIG. 2 may carry out the various implementations described herein of eagerly invalidating or flushing PIM data from the caches. Some of the implementations are described above with respect to FIG. 1 and operate in a similar manner except that the PIM device, rather than being implemented as part of the memory device itself is implemented as an accelerator that is a separate component from the memory device.

[0056] For further explanation, FIGS. 3 and 4 set forth flow charts illustrating various example methods of eagerly invalidating and flushing cached data used by PIM instructions according to implementations of the present disclosure. Each of the methods can be carried out in and by the example systems of FIGS. 1 and 2 above.

[0057] Beginning with FIG. 3, a processor core 106 receives 312 one or more PIM instructions 306 where at least one of the PIM instructions includes a memory operand. For example, the memory operand can specify a memory location that is the target of a load or store operation to be performed in a PIM device. In some examples, the PIM instruction 306 is part of a kernel that is offloaded for execution by the PIM device. For example, the PIM instruction 306 can be part of a loop of instructions. The region of source code or machine language code that includes the PIM instruction can be marked with a start region marker and an end region marked that is inserted by the application developer or by the compiler.

[0058] A PIM instruction is considered “executed” in the core 106 by resolving 314 memory addresses and data dependencies for the PIM instruction 306. Metadata, such as the resolved physical memory address and operand from core 106 registers, is coupled with the PIM instruction and ultimately dispatched to the PIM device.

[0059] The memory address may be provided to the core 106 for resolving (from a virtual address to physical address for example) int various forms. In some forms, the memory address resolved 314 by the core 106 is received as part of the PIM instruction 306 itself. In other implementations, the memory address is specified in a cache control instruction associated with the PIM instruction. A cache control instruction is an instruction to flush, invalidate, or flush and invalidate a cache line associated with a memory address. The cache control instruction can be included by an application developer or by a compiler in source code or machine code for the application or thread containing the PIM instruction 306. For example, the cache control instruction can be a flush cache line (CLFUSH) or Data Cache Block Flush (DCBF) instruction to flush a cache line, or a Data Cache Block Invalidate (DCBI) instruction to invalidate a cache line. Such cache control instructions and variants thereof are supported by several processor instruction set architectures, including PowerPC and x86.

[0060] In some implementations, a cache control instruction is interleaved in a plurality of PIM instructions. For example, a cache control instruction can be executed by the core 106 in a loop of PIM instructions prior to executing a PIM instruction 306 that targets the memory address identified in the cache control instruction. In other examples, a cache control instruction is executed by a core 106 prior to entering a code sequence that includes one or more PIM instructions 306. For example, a cache control instruction can be executed prior to a transaction-start instruction that signifies the beginning of a series of PIM instructions 306. In this way, the cache control instruction that targets a physical memory address is executed before a PIM instruction that targets the same physical memory address to allow the developer or compiler to ensure that the PIM instruction is using the most recent data and that other non-offload instructions do not access stale data.

[0061] Once the processor core 106 resolves 314 the physical memory address associated with the PIM instruction 306, the processor core 106 dispatches 316 a cache probe request 301 based on the resolved physical memory address to the coherency synchronizer 134. The cache probe request notifies the coherency synchronizer to invalidate or flush cache entries in system caches associated with the physical memory address.

[0062] The coherency synchronizer receives 310 the cache probe request 301 and issues 320 a cache probe 308 to one or more caches based on the physical memory address prior to receiving the PIM instruction 306 for dispatch to the PIM device. The cache probe 308 can be a probe to invalidate a clean cache line associated with the physical memory address, a probe to flush a dirty cache line associated with the physical memory address, or a probe to flush and invalidate a dirty cache line associated with the physical address. For example, the cache probe 308 can flush dirty data in a cache entry corresponding to the physical memory address to be read by a remote_load instruction when executed at the PIM device to ensure that the PIM device utilizes the most current data that is stored in the cache entry. In some examples, the cache probe 308 can invalidate data in a cache entry corresponding to a physical memory address that is the destination of a remote_store instruction when executed at the PIM device so that younger instructions do not read stale data. Each cache that receives the cache probe 308 sends a probe response back to the system probe filter indicating the appropriate cache operations have completed.

[0063] In some implementations, the cache coherency synchronizer issues 320 the cache probe 308 by employing a system probe filter to identify caches in the processor system, including caches across multiple core complexes, that hold data associated with the physical memory address. The system probe filter issues the cache probe prior to the coherency synchronizer 134 receiving the PIM request. That is, for a PIM instruction that targets the physical memory address, the cache probe is issued from the system probe filter before the PIM instruction is dispatched from the core 106 to the coherency synchronizer. In this way, cache flushing and invalidating of PIM data can be initiated earlier in time than would have otherwise occurred and PIM instruction dispatch throughput may be increased.

[0064] The method of FIG. 3 continues by the processor core 106 dispatching 317 the PIM instruction. As mentioned above, the core 106 places the PIM instruction in a PIM queue for later dispatch through the memory controller to the PIM device. As such, the PIM instruction often is held in that PIM queue for a relatively long period of time. Once the core 106 eventually dispatches the PIM instruction 306 to the PIM device through the memory controller (not shown in this figure), the coherency synchronizer ‘receives’ 322 the PIM instruction from the core 106 by intercepting the PIM instruction prior to the instruction reaching the memory controller (136 in FIG. 1 and FIG. 2). The core 106 dispatches 317 the PIM instruction along with operators and operands for the PIM instruction as well as metadata such as the resolved memory address, scalar values utilized by the PIM instruction, and so on. Additionally, the PIM instruction may be included in a group of similar PIM instructions with associated operators, operands, and metadata. The path of the dispatch of a PIM instruction begins at the core 106 and travels through the memory controller (136 in FIG. 1 and FIG. 2) which will eventually dispatch the PIM instruction to the PIM device. The coherency synchronizer intercepts the PIM instruction between the core 106 and the memory controller. In some implementations, the coherency synchronizer 134 receives the PIM instruction 306 directly from the core 106, bypassing the caches 328, after the core 106 retires the PIM instruction. The caches 328 in the example of FIG. 3 include all of the L1, L2, L3/LLC caches displayed in FIG. 1 and FIG. 2.

[0065] After the PIM instruction is received from the core 106, the coherency synchronizer 134 determines whether probe responses 326 for the cache probe 308 have been received from the caches 328. A cache probe response indicates that the cache line invalidation or cache line flush operation (whichever was requested in the cache probe) has completed. In the method of FIG. 3, when a probe response has been received for all caches to which a cache probe has been sent, the coherency synchronizer 134 dispatches 324 the PIM instruction 306 to the PIM device 318. That is, the PIM instruction need only wait to be dispatched to the PIM device until the cache probe related to that PIM instruction is completed. In addition, the cache probe was initiated prior to the PIM instruction's arrival at the coherency synchronizer 134. It is noted that the coherency synchronizer 134 dispatches 324 the PIM instruction ‘to the PIM device’ in that the coherency synchronizer forwards the PIM instruction to the memory controller which then dispatches the instruction to the PIM device.

[0066] By the time the PIM instruction 306 is dispatched from the core 106, the cache probe 308 is already in flight and, in some cases, the coherency synchronizer 134 may have already received some or all the probe responses. When the PIM instruction arrives at the coherency synchronizer, the system probe filter will determine that the cache probe 308 has already been issued for the physical memory address identified in the PIM instruction. If probe responses have been received for the cache probe 308, the PIM instruction is dispatched to the memory controller for eventual PIM execution. If the cache probe responses have not been received, the PIM instruction waits at the coherency synchronizer 134 until the responses have been received, at which time the PIM instruction can be dispatched to the memory controller. Although the PIM instruction may still wait at the coherency synchronizer for probe responses to be received, probe response latency is greatly reduced by issuing the cache probes before the PIM instruction is received at the system probe filter of the coherency synchronizer 134.

[0067] In some embodiments, probe response latency can be reduced even more through speculative issuance of cache probes. For further explanation, therefore, FIG. 4 sets forth a flowchart illustrating a method of eagerly invalidating and flushing cached PIM data through speculative issuance of cache probes according to implementations of the present disclosure. The method of FIG. 4 includes a processor core 106 receiving 401 a first PIM instruction 402. In the example of FIG. 4, the first PIM instruction 402 includes or is otherwise associated with a first memory address. The core 106 may resolve the memory address and provide the memory address to a coherency synchronizer 134 in a similar manner to that described above.

[0068] Based on at (at least) the first PIM instruction 402 and the first physical memory address 404, the coherency synchronizer 134 speculates 406 a second physical memory address. In some implementations, for example, the cache coherency synchronizer may identify a pattern of previous PIM instruction memory addresses and speculate one or more additional memory addresses. This may be especially accurate for loops in which the same patterns of PIM instructions and the corresponding memory addresses are utilized in a repetitive manner.

[0069] Once the second address 408 is speculated, the coherency synchronizer issues 410 a cache probe 412 to one or more caches. The cache probe 412 in this example is an indication to caches to flush, invalidate, or flush and invalidate cache lines that include data at the second address 408. It is noted that the cache probe here is issued in some cases before a second PIM is ever received at the core for execution. In fact, in some cases a second PIM instruction associated with the second address 408 may never arrive at the core 106. Said another way, the cache probe 412 for the second address is speculatively issued before ever encountering a second PIM instruction that specifies the second physical memory address.

[0070] In some instances, however, the coherency synchronizer 134 receives 416 the second PIM instruction 414 after the second PIM instruction 414 is dispatched by the processor core 401. In such an example, the cache coherency synchronizer 134 then determines whether probe responses to the cache probe 412 for the second address 408 have been received from the caches. When all required probe responses have been received, the coherency synchronizer 134 dispatches 420 the second PIM instruction 414 to the PIM device (through the memory controller for execution). In this way, well before a PIM instruction is received at the coherency synchronizer, a cache flush or invalidation of data used by the PIM instruction may initiated. Thus, latency of cache probe responses and the resulting latency of executing a PIM instruction is reduced.

[0071] In view of the above description, readers will appreciate the above implementations directed to eagerly invalidating and flushing cached data used by offloaded operations in accordance with the present disclosure provide numerous advantages. Readers will appreciate that the above-described mechanisms for early data invalidation and flushing from caches will improves the dispatch bandwidth of offloaded computations to remote execution logic, such as PIM devices. PIM requests will spend less time in queues waiting for cache probe responses prior to being dispatched to the remote execution logic. Readers will appreciate that implementations enable high dispatch bandwidth of work to remote execution logic by eagerly invalidating and flushing data lines from caches that will be utilized by the remote execution logic. Readers will appreciate that implementations will reduce the coherence overhead experienced by request traffic destined for the remote execution logic, thereby improving the PIM request arrival rate at the remote execution logic and overall performance.

[0072] Implementations can be a system, an apparatus, a method, and/or logic circuitry. Computer readable program instructions in the present disclosure can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. In some implementations, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions.

[0073] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and logic circuitry according to some implementations of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by logic circuitry.

[0074] The logic circuitry can be implemented in a processor, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the processor, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0075] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and logic circuitry according to various implementations of the present disclosure. In this regard, each block in the flowchart or block diagrams can represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0076] While the present disclosure has been particularly shown and described with reference to implementations thereof, it will be understood that various changes in form and details can be made therein without departing from the spirit and scope of the following claims. Therefore, the implementations described herein should be considered in a descriptive sense only and not for purposes of limitation. The present disclosure is defined not by the detailed description but by the appended claims, and all differences within the scope will be construed as being included in the present disclosure.