Extend cache snooping mode for coherency protection of certain requests

Abstract

The cache memory includes a data array, a directory of contents of the data array specifying consistency state information, and snooping logic that handles snooping operations from a system structure by referencing the data array and the directory. The snooping logic determines whether the cache memory has consistency ownership of the target address in response to a request for a first refresh or clean memory access operation that specifies a target address snooped on the system structure. Based on determining that the cache memory has consistency ownership of the target address, the snooping logic services the request and thereafter enters a referee mode. When in referee mode, the snooping logic protects a memory block identified by the target address from conflicting memory access requests from multiple processor cores until a second refresh / clean memory access operation that specifies the target address is completed.

Description

Background Art

[0001] The present invention relates generally to data processing and, more particularly, to a cache snooping mode that extends coherency protection for flush / clean memory access requests that update system memory.

[0002] A conventional multiprocessor (MP) computer system, such as a server computer system, includes multiple processing units, all coupled to a system interconnect, which typically includes one or more address, data, and control buses. Coupled to the system interconnect is system memory, which represents the lowest level of shared memory in a multiprocessor computer system and is typically accessible for read and write by all processing units. To reduce access latency to instructions and data residing in system memory, each processing unit is also typically supported by a corresponding multi-level cache hierarchy, the lower levels of which may be shared by one or more processor cores.

[0003] Cache memory is typically used to temporarily buffer memory blocks that may be accessed by a processor in order to speed up processing by reducing access delays introduced by having to load required data and instructions from system memory. In some MP systems, the cache hierarchy includes at least two levels. Level 1 (L1) or higher level caches are typically dedicated caches associated with a specific processor core and cannot be accessed by other cores in the MP system. Typically, in response to a memory access instruction such as a load or store instruction, the processor core first accesses the directory of the higher level cache. If the requested memory block is not found in the higher level cache, the processor core accesses a lower level cache (e.g., level 2 (L2) or level 3 (L3) cache) for the requested memory block. The lowest level cache (e.g., L2 or L3) can be shared by multiple processor cores.

[0004] Because multiple processor cores can request write access to the same cache line of data, and because modified cache lines are not immediately synchronized with system memory, the cache hierarchy of a multi-processor computer system typically implements a cache coherence protocol to ensure at least a minimum level of consistency of the contents of system memory between the various processor cores. In particular, cache coherence requires, at a minimum, that after a hardware thread accesses a copy of a memory block and subsequently accesses an updated copy of the memory block, the hardware thread cannot again access the old copy of the memory block.

[0005] Some MP systems support refresh and clean operations, which cause the modified cache line associated with the target address of the refresh or clean operation to be copied back to system memory from a unique cache hierarchy that contains the cache line (if any) in a coherence state (sometimes referred to herein as "HPC" state) that indicates write permission. For a clean operation, the target cache line is also transitioned to an unmodified HPC coherence state. For a refresh operation, the target cache line in the HPC state, whether modified or not, if any, is transitioned to an invalid coherence state. The refresh operation also requires that any other one or more copies of the target cache line in a non-HPC state be invalidated in all cache hierarchies of the MP system. This invalidation may not be completed when the cache (if any) holding the target cache line in the HPC state has completed its processing.

[0006] In an MP system that maintains coherence via a snoop-based coherence protocol, a flush or clean operation is typically broadcast over the system interconnect of the MP system and receives a retry coherence response as long as the cache holding the target cache line in HPC state has not yet completed processing the flush or clean operation. Thus, the coherence participant initiating the flush or clean operation may need to reissue the flush or clean operation multiple times before the cache holding the target cache line in HPC state (if any) has completed its processing of the flush or clean operation. When the cache holding the target cache line in HPC state has completed processing the flush or clean operation, and if a new copy of the target cache line in HPC state has not yet been created (in modified HPC state for a flush operation, or in modified or unmodified HPC state for a refresh operation), subsequent issuances of the flush operation will receive a coherence response indicating success, and subsequent issuances of the refresh operation will receive a coherence response indicating success (if no cached copy of the line exists) or receive a coherence response that transfers the responsibility for invalidating any remaining non-HPC cached copies of the target cache line to the initiating coherence participant. In either of these cases of a refresh operation, the refresh operation may be considered to have "succeeded" in the sense that the refresh operation has been fully completed or will be completed once the remaining non-HPC copies of the target cache line have been invalidated by the initiating coherence participant (e.g., by issuing a kill operation). However, if, before a subsequent clean or refresh operation is issued, another coherence participant creates a new copy of the target cache line in the relevant HPC state (i.e., in the modified HPC state for the clean operation, and in either the modified or unmodified HPC state for the refresh operation), then a subsequent re-issuance of the refresh or clean operation will again be retried and will have to process the new copy of the target cache line in the HPC state, thereby delaying the successful completion of the refresh or clean operation. This delay may be further exacerbated by the continuous creation of new HPC copies of the target cache line of the refresh or clean operation. Summary of the Invention

[0007] In at least one embodiment, a target cache line of a flush or scrub operation is protected from competing accesses from other coherence participants by a designated coherence participant providing protection for the target cache line.

[0008] In at least one embodiment, a cache memory includes a data array, a directory specifying the contents of the data array of consistency state information, and snoop logic for handling operations snooped from a system structure by referencing the data array and the directory. The snoop logic, in response to a request for a first refresh / clean memory access operation specifying a target address snooped on the system structure, determines whether the cache memory has consistency ownership of the target address. Based on determining that the cache memory has consistency ownership of the target address, the snoop logic services the request and thereafter enters an adjudication mode. While in adjudication mode, the snoop logic protects the memory block identified by the target address from conflicting memory access requests from multiple processor cores until a second refresh / clean memory access operation specifying the same target address is snooped, accepted, and successfully completed. As a result, no other cache can obtain consistency ownership of the target cache line between the first and second refresh / clean memory access operations, thereby eliminating a source of potential delay in completing the requested refresh or clean. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0010] Figure 1 is a high-level block diagram of an exemplary data processing system according to one embodiment;

[0011] Figure 2 is a more detailed block diagram of an exemplary processing unit according to one embodiment;

[0012] Figure 3 is a detailed block diagram of a lower level cache according to one embodiment;

[0013] Figure 4 is an exemplary timing diagram of a processor memory access operation according to one embodiment;

[0014] Figure 5 is a high-level logic flow diagram of an exemplary process for a processing unit to perform a flush / scrub memory access operation according to one embodiment;

[0015] Figure 6 is a high-level logical flow diagram of an exemplary process by which a cache having coherent ownership of a target cache line of a snooped refresh or clean type request processes the request, according to one embodiment;

[0016] Figure 7 is a timing diagram of an exemplary refresh / scrub memory access operation according to one embodiment;

[0017] Figure 8is a high-level logic flow diagram of an exemplary process by which a cache maintaining a non-HPC shared copy of a target cache of a snooped request of a flush type processes the request, according to one embodiment; and

[0018] Figure 9 is a data flow diagram showing the design process. DETAILED DESCRIPTION

[0019] Referring now to the drawings, wherein like reference numerals designate like and corresponding parts throughout, and particularly to Figure 1 , a high-level block diagram depicting an exemplary data processing system 100 according to one embodiment is shown. In the depicted embodiment, data processing system 100 is a cache-coherent multiprocessor (MP) data processing system that includes a plurality of processing nodes 102 for processing data and instructions. Processing nodes 102 are coupled to a system interconnect 110 for communicating address, data, and control information. System interconnect 110 can be implemented as, for example, a bus interconnect, a switch interconnect, or a hybrid interconnect.

[0020] In the depicted embodiment, each processing node 102 is implemented as a multi-chip module (MCM) containing four processing units 104, each of which is preferably implemented as a respective integrated circuit. The processing units 104 within each processing node 102 are coupled to communicate with each other and with the system interconnect 110 via a local interconnect 114, which is similar to the system interconnect 110 and may be implemented, for example, using one or more buses and / or switches. Together, the system interconnect 110 and the local interconnect 114 form a system fabric.

[0021] As the following reference Figure 2 As described in more detail, processing units 104 each include a memory controller 106 coupled to a local interconnect 114 to provide an interface to a corresponding system memory 108. Data and instructions residing in system memory 108 can generally be accessed, cached, and modified by a processor core in any processing unit 104 of any processing node 102 within data processing system 100. System memory 108 thus forms the lowest level of memory storage in the distributed shared memory system of data processing system 100. In alternative embodiments, one or more memory controllers 106 (and system memory 108) may be coupled to system interconnect 110 instead of local interconnect 114.

[0022] Those skilled in the art will understand that Figure 1 The MP data processing system 100 may include many additional components not shown, such as interconnect bridges, non-volatile memory, ports for connecting to a network, or attached devices, etc. Because these additional components are not necessary for understanding the described embodiments, they are not described in detail. Figure 1 However, it should also be understood that the enhancements described herein are applicable to data processing systems of different architectures and are in no way limited to Figure 1 The generalized data processing system architecture shown in .

[0023] Now refer to Figure 2 , depicts a more detailed block diagram of an exemplary processing unit 104 according to one embodiment. In the depicted embodiment, each processing unit 104 is an integrated circuit that includes multiple processor cores 200 for processing instructions and data. Each processor core 200 includes one or more execution units for executing instructions, including an LSU 202 that executes memory access instructions that request access to a memory block or result in a request to access a memory block. In at least some embodiments, each processor core 200 is capable of independently executing multiple hardware execution threads simultaneously.

[0024] The operation of each processor core 200 is supported by a multi-level memory hierarchy having, at its lowest level, a shared system memory 108 accessed via an integrated memory controller 106. At its higher levels, the memory hierarchy includes one or more levels of cache memory, which, in the illustrative embodiment, includes a store-through level one (L1) cache 226 within and dedicated to each processor core 200, and a corresponding store-in level two (L2) cache 230 for each processor core 200. To efficiently handle multiple concurrent memory access requests to cacheable addresses, in some embodiments, each L2 cache 230 may be implemented with multiple L2 cache slices, each cache slice handling memory access requests to a corresponding set of real memory addresses.

[0025] Although the cache hierarchy shown includes only two levels of cache, those skilled in the art will understand that alternative embodiments may include additional levels (e.g., L3, L4, etc.) of on-chip or off-chip inline or look-aside cache that may fully, partially, or exclude the contents of higher level caches.

[0026] Still refer to Figure 2 Each processing unit 104 also includes an integrated and distributed fabric controller 216 responsible for controlling the flow of operations on the local interconnect 114 and the system interconnect 110, and response logic 218 for determining coherence responses to memory access requests used in a selected cache coherence protocol.

[0027] In operation, when a hardware thread executed by processor core 200 includes a memory access instruction requesting execution of a specified memory access operation, LSU 202 executes the memory access instruction to determine the target real address to be accessed. If the requested memory access cannot be fully executed by referencing L1 cache 226 of executing processor core 200, processor core 200 generates a memory access request including, for example, at least a request type and a target real address, and sends the memory access request to its associated L2 cache 230 for processing.

[0028] Now refer to Figure 3 , shows a more detailed block diagram of an example embodiment of an L2 cache 230 according to one embodiment. Figure 3 As shown, the L2 cache 230 includes a cache array 302 and a directory 308 for the contents of the cache array 302. Assuming that the cache array 302 and the directory 308 are conventional set-associative, a memory location in the system memory 108 is mapped to a specific congruence class within the cache array 302 using predetermined index bits within the system memory (real) address. The specific memory blocks stored within the cache lines of the cache array 302 are recorded in the cache directory 308, which contains one directory entry for each cache line. Although Figure 3 Not explicitly shown, but understood by those skilled in the art, each directory entry in the cache directory 308 includes various fields, such as a tag field that identifies the real address of the memory block held in the corresponding cache line of the cache array 302, a status field that indicates the coherency status of the cache line, an LRU (least recently used) field that indicates the replacement order of the cache line relative to other cache lines in the same congruence class, and an inclusive field that indicates whether the memory block is held in the associated L1 cache.

[0029] The L2 cache 230 includes a plurality (e.g., 16) of Read-Claim (RC) engines 312a-312n for independently and concurrently servicing memory access requests received from the associated processor core 200. To service remote memory access requests originating from processor cores 200 other than the associated processor core 200, the L2 cache 230 also includes a plurality of Snoop (SN) engines 311a-311m. Each SN engine 311 can independently and concurrently process remote memory access requests "snooped" from the local interconnect 114. As will be appreciated, the servicing of memory access requests by the RC engines 312 may require the replacement or invalidation of memory blocks within the cache array 302. Accordingly, the L2 cache 230 includes a CO (castout) engine 310, which manages the removal and write-back of memory blocks from the cache array 302.

[0030] The L2 cache 230 also includes an arbiter 305 that controls the multiplexers M1-M2 to order the processing of local memory access requests received from the associated processor core 200 and remote requests snooped on the local interconnect 114. Based on the arbitration policy implemented by the arbiter 305, the memory access requests are forwarded to the dispatch logic 306, which processes the memory access requests with respect to the directory 308 and the cache array 302 over a given number of cycles.

[0031] L2 cache 230 also includes an RC queue (RCQ) 320 and a castout push intervention (CPI) queue 318, which buffer data inserted into and removed from cache array 302, respectively. RCQ 320 includes multiple buffer entries, each of which corresponds individually to a specific one of RC engines 312, allowing each assigned RC engine 312 to retrieve data only from the designated buffer entry. Similarly, CPI queue 318 includes multiple buffer entries, each of which corresponds individually to a corresponding one of CO engines 310 and SN engines 311, allowing each assigned snooper 311 and CO engine 310 to retrieve data only from the corresponding designated CPI buffer entry.

[0032] Each RC engine 312 also has assigned to it a respective one of a plurality of RC data (RCDAT) buffers 322 for buffering memory blocks read from the cache array 302 and / or received from the local interconnect 114 via the reload bus 323. The RCDAT buffer 322 assigned to each RC engine 312 is preferably configured with connections and functions corresponding to the memory access requests that can be serviced by the associated RC engine 312. The RCDAT buffer 322 has an associated memory data multiplexer M4 that selects data bytes from among its inputs for buffering in the RCDAT buffer 322 in response to a select signal, not shown, generated by the arbiter 305.

[0033] In operation, a processor store request, including a request type (ttype), a target real address, and store data, is received from an associated processor core 200 within store queue (STQ) 304. The store data is transmitted from STQ 304 via data path 324 to store data multiplexer M4, and the store type and target address are passed to multiplexer M1. Multiplexer M1 also receives as input processor load requests from processor core 200 and directory write requests from RC engine 312. In response to a select signal generated by arbiter 305 (not shown), multiplexer M1 selects one of its input requests to forward to multiplexer M2, which also receives as input a remote request received from local interconnect 114 via remote request path 326. Arbiter 305 schedules local and remote memory access requests for processing and generates a sequence of select signals 328 based on the schedule. In response to the select signal 328 generated by the arbiter 305 , the multiplexer M2 selects the local request received from the multiplexer M1 or the remote request snooped from the local interconnect 114 as the next memory access request to be processed.

[0034] Now refer to Figure 4 , which depicts Figure 1 FIG1 is a time-space diagram of exemplary operations on the system architecture of data processing system 100, it being understood that at any given time, there will be many such operations in progress on the system architecture, and in some operational scenarios, multiple of these concurrent operations may specify conflicting target addresses.

[0035] Operation begins at the request stage 450, where the host 400, such as the RC engine 312 of the L2 cache 230, issues a request 402 on the system architecture. The request 402 preferably includes at least a request type indicating the type of access desired and a resource identifier (e.g., a real address), wherein the request type indicates the type of access desired and the resource identifier indicates the resource to be accessed by the request. The request preferably includes those set forth in Table 1 below.

[0036] Table I

[0037]

[0038]

[0039] Request 402 is received by snoopers 404a-404n distributed throughout data processing system 100, such as SN engines 311a-311m of L2 cache 230 and a not-shown snooper in memory controller 106. For read-type requests, SN engine 311 in the same L2 cache 230 as host 400 of request 402 does not snoop request 402 (i.e., there is typically no self-snooping), because request 402 is only transmitted across the system fabric when the read-type request 402 cannot be serviced internally by processing unit 104. However, for other types of requests 402, such as flush / clean requests (e.g., DCBF, DCBST, and AMO requests listed in Table 1), SN engine 311 in the same L2 cache 230 as host 400 of request 402 performs self-snooping on request 402.

[0040] Operation continues to a partial response phase 455. During the partial response phase 455, each snooper 404 that receives and processes the request 402 provides a respective partial response ("Presp") 406 representing at least that snooper's 404 response to the request 402. A snooper 404 within the integrated memory controller 106 determines which partial response 406 to provide based on, for example, whether the snooper 404 is responsible for the request address and whether it has resources currently available to service the request. A snooper 404 of the L2 cache 230 may determine its partial response 406 based on, for example, the availability of its L2 cache directory 308, the availability of the snoop logic instance 311 within the snooper 404 to process the request, and the coherency state (if any) associated with the request address in the L2 cache directory 308.

[0041] Operation continues to the combine response phase 460. During the combine response phase 460, the partial responses 406 of the snooper 404 are logically combined in stages or all at once by one or more instances of the response logic 218 to determine a system-wide combined response ("Cresp") 410 to the request 402. In a preferred embodiment, which will be assumed hereinafter, the instance of the response logic 218 responsible for generating the combined response 410 is located in the processing unit 104 containing the host 400 that issued the request 402. The response logic 218 provides the combined response 410 to the host 400 and the snooper 404 via the system fabric to indicate the system-wide response (e.g., success, retry, etc.) to the request 402. If Cresp 410 indicates success of request 402, Cresp 410 may indicate, for example, the source of the data for the requested memory block (if applicable), the coherency state of the requested memory block to be cached by the host 400 (if applicable), and whether a "clean" operation is required to invalidate cached copies of the requested memory block in one or more L2 caches 230 (if applicable).

[0042] In response to receiving the combined response 410, one or more of the host 400 and the snooper 404 typically performs one or more operations to service the request 402. These operations may include providing data to the host 400, invalidating or otherwise updating the coherence state of data cached in one or more L2 caches 230, performing a throw operation, writing data back to the system memory 108, etc. If required by the request 402, the requested or target memory block may be sent to or from one of the host 400 or the snooper 404 before or after the response logic 218 generates the combined response 410.

[0043] In the following description, a partial response 406 of the snooper 404 to the request 402 and the operations and / or combined responses 410 performed by the snooper 404 in response to the request 402 will be described with reference to whether the request address specified by the snooper 404 with respect to the request 402 is the highest point of coherence (HPC), the lowest point of coherence (LPC), or neither. An LPC is defined herein as a memory device or I / O device that serves as a final repository for a memory block. In the absence of a cache participant that maintains a copy of the memory block, the LPC maintains a unique image of the memory block. In the absence of an HPC cache participant for the memory block, the LPC has the sole authority to grant or deny a request to modify the memory block. In addition, when the LPC data is current data and there is no cache participant that can provide the data, the LPC provides the data to the request to read or modify the memory block. If a cache participant has a more current copy of the data but cannot provide it to the request, the LPC does not provide the stale data and the request is retried. For Figures 1 to 3 In a typical request in the embodiment of data processing system 100 given in , the LPC would be the memory controller 106 of system memory 108 that holds the referenced memory block.

[0044] The HPC is defined herein as a uniquely identified device that caches a true image of a memory block (which may or may not be consistent with the corresponding memory block at the LPC) and has authorization to grant or deny requests to modify the memory block. Descriptively, the HPC (even if its copy is consistent with main memory behind the LPC) provides a copy of the memory block to the requestor in response to any request to read or modify the memory block (cache-to-cache transfers are faster than LPC-to-cache transfers). Thus, for a typical request in an embodiment of a data processing system, the HPC (if any) will be the L2 cache 230. Although other indicators can be used to specify the HPC of a memory block, the preferred embodiment uses the selected cache coherency state within the L2 cache directory 308 of the L2 cache 230, if any, to specify the HPC of the memory block. In a preferred embodiment, the coherence state within the coherence protocol indicates, in addition to (1) whether the cache is the HPC for the memory block, (2) whether the cached copy is unique (i.e., is the only cached copy at the system level), (3) whether and when the cache can provide a copy of the memory block to a host requesting the memory block relative to the stage of operation, and (4) whether the cached image of the memory block is consistent with the corresponding memory block at the LPC (system memory). These four properties can be expressed, for example, in an exemplary variation of the well-known MESI (Modified, Exclusive, Shared, Invalid) protocol summarized below in Table II. Further information on coherence protocols can be found, for example, in U.S. Patent 7,389,388, which is incorporated herein by reference.

[0045] Table II

[0046]

[0047]

[0048] It is worth noting in Table II above that T, Te, S Land S states, which are all "shared" coherence states in that a cache memory can simultaneously maintain a copy of a cache line held by another cache memory in any of these states. The T or Te state identifies the HPC cache memory that previously held the associated cache line in one of the M or Me states, respectively, and initiated a query-only copy of the associated cache line to another cache memory. As an HPC, the cache memory holding a cache line in the T or Te coherence state has the authority to modify the cache line or to grant such authority to another cache memory. The cache memory holding a cache line in the Tx state (e.g., T or Te) serves as the cache data source of last resort (after Cresp) for the query-only copy of the cache line because if the cache line is not held in the S L If a cache memory of state is available to serve as a data source (before Cresp), then the cache memory will only provide query-only copies to another cache memory.

[0049] S L The S state is formed at a cache memory in response to the cache memory receiving a lookup-only copy of a cache line from a cache memory in the T coherency state. L The state is not HPC coherent, but keeps the cache line in S L The cache memory in the state has the ability to use the query-only copy of the cache line as a source for another cache memory and can do so before receiving Cresp. In response to using the query-only copy of the cache line as a source for another cache memory (which assumes S L state), the cache memory that is the source of the query-only copy of the cache line changes its coherence state for the cache line from S L Update to S. Therefore, S L Implementation of a coherence state may enable many query-only copies of frequently queried cache lines to be created throughout a multiprocessor data processing system, reducing latency for query-only accesses to these cache lines.

[0050] Reference again Figure 4 For the memory block referenced in request 402, if an HPC is present, or if no HPC is present, the LPC of the memory block preferably has the responsibility to protect the transfer of coherent ownership of the memory block in response to request 402 (if necessary). Figure 4In the exemplary scenario shown, a snooper 404n at the HPC (or, in the absence of an HPC, the LPC) of a memory block specified by a request address of a request 402 protects the transfer of coherent ownership of the requested memory block to a host 400 during a protection window 412a, which extends from the time the snooper 404n determines its partial response 406 until the snooper 404n receives a combined response 410, and during a subsequent window extension 412b that extends a programmable time beyond the snooper 404n's receipt of the combined response 410. During the protection window 412a and the window extension 412b, the snooper 404n protects the transfer of ownership by providing partial responses 406 to other requests specifying the same request address, which prevent other hosts from obtaining ownership (e.g., retrying the partial response) until ownership has been successfully transferred to the host 400. Host 400 may similarly initiate protection window 413 to protect its coherent ownership of the memory block requested in request 402 after receiving combined response 410 .

[0051] Because snooper 404 all has the limited resource that is used to process above-mentioned CPU and I / O request, so several different levels of Presp and corresponding Cresp are possible.For example, if the snooper in the memory controller 106 of the memory block being responsible for request has the queue that can be used for processing request, then snooper can respond with the partial response of indicating that it can be used as the LPC of request.On the other hand, if snooper does not have queue to be used for processing request, then snooper can respond with the partial response of indicating that it is the LPC of memory block but can not serve this request currently.Similarly, the snooper 311 in L2 cache 230 may need the available instance of snoop logic and access L2 cache directory 406 to process request.Lack of access to any one (or both) of these resources causes partial response (and corresponding Cresp) signaling notification to not be able to serve this request owing to lack required resources.

[0052] As described above, in systems implementing snoop-based coherence protocols, flush operations (e.g., DCBF and AMO) and clean operations (e.g., DCBST) may suffer from forward progress issues in the window of vulnerability between the completion of the flush / clean operation in the cache hierarchy containing the target cache line in the dirty HPC state (if any) and the host that initiated the ultimately successful flush / clean request. Figures 5 to 8 As described in detail, these forward progress issues can be resolved by having the coherence participant (ie, the HPC) with coherence ownership of the target cache line extend its protection window for the target cache line.

[0053] Now go to Figure 5 , shows a high-level logic flow diagram of an exemplary process for a master 400 (e.g., RC engine 312) in a processing unit 104 to perform a refresh or scrub type memory access operation according to one embodiment. As indicated above, any number of masters may concurrently perform their own respective refresh / scrub memory access operations on potentially conflicting target addresses. Thus, multiple masters may be executed within the data processing system 100 in a temporally overlapping manner. Figure 5 Multiple examples of the process are given in .

[0054] Figure 5 The process begins at block 500 and then proceeds to block 502, which illustrates a host 400 issuing a request 402 for a memory access operation on the system architecture of the data processing system 100. In at least some embodiments, the host 400, such as the RC engine 312 of the L2 cache 230, issues the request 402 in response to receiving a memory access request from an associated processor core 200 based on the execution of a corresponding instruction by the LSU 202. In the described embodiment, the request 402 initiates a memory access operation that belongs to one of several classes or types of operations, collectively referred to herein as flush / scrub (FC) operations. These FC operations include the DCBF, DCBST, and AMO operations referenced in Table 1, which are all store-modify operations that require a cached copy of any modifications to a target memory block to be written back to the associated system memory 108.

[0055] As in Figure 4 As is clear from the foregoing discussion, the FC request 402 from the host 400 is received by the L2 cache 230 and the memory controller 106 distributed within the data processing system 100 in a system architecture. In response to receipt of the FC request 402, these various snoopers 404 generate their respective partial responses 406 and transmit the partial responses 406 to the relevant instance of the response logic 218. In an exemplary embodiment, the L2 cache 230 responds to the snooped FC request 402 with one of three Presp: (1) heavyweight retry, (2) lightweight retry, or (3) null. The heavyweight retry Presp is provided by an L2 cache 230 that currently cannot access the coherence state of the target address of the FC request 402 in its directory 308. In addition, the heavyweight retry Presp is also provided by an L2 cache 230 that is designated as the HPC of the target address by the coherence state in its directory 308, but cannot respond to the FC request 402 at this time, or is currently busy processing a request for the target cache line.

[0056] Lightweight Retry Prep is provided by the L2 cache 230 whose directory 308 is accessible and indicates the S of the target address. Land S states, and (1) another conflicting request for the target address is currently being processed, or (2) the SN engine 311 cannot be dispatched and the SN engine 311 is not currently active for the target address, or (3) the SN engine 311 has been dispatched to process the FC request 402.

[0057] It should be understood that for the entire interval, the L2 cache 230 has the SN engine 311 active to process requests for a given target address, and when the request is first snooped, the L2 cache 230 will provide a heavyweight retry Presp or a lightweight retry Presp based on the coherency state associated with the target address. Figure 6 The specific actions performed by the L2 cache 230 to maintain the target address of the FC request 402 in a dirty HPC (eg, M or T) coherency state are described in detail. Figure 7 Detailed description of the process of maintaining the target address of the refresh request in a shared (eg, Te, S L or S) coherence state of the L2 cache 230.

[0058] In response to the snoop FC request 402, the memory controller 106 that is not responsible for the target address (i.e., not responsible for the LPC) will not provide a Presp (or a null Presp). If the memory controller 106 cannot service the FC request 402 due to resource limitations or because the memory controller 106 is already servicing another memory access request specifying the same address, the memory controller 106 that is the LPC memory controller of the target address of the FC request 402 provides a Retry_LPC Presp. If the LPC memory controller 106 is able to service the FC request 402, the LPC memory controller 106 protects the target address of the FC request 402 by providing an LPC_Retry Presp for any subsequent FC operations (or other operations) until it receives a successful Cresp for the originally snooped FC request 402.

[0059] Reference again Figure 5 , the process proceeds from block 502 to blocks 504, 505, and 506, which illustrate that the host 400, which issued the request 402 for the FC operation at block 502, waits to receive the corresponding Cresp 410 from the response logic 218. In at least one embodiment, the response logic 218 may generate the Cresp 410 for the FC operation based on the received Presp of the snooper 404 as shown in Table III below. It should be noted that in at least some embodiments, the DCBST request does not receive a lightweight retry Presp (as shown in rows 1, 2, 3, and 5 of Table III) because the DCBST request is cached by keeping the cache line in S L Caches in any of the S and S states are ignored.

[0060] Table III

[0061]

[0062]

[0063] In response to receiving Cresp 410, host 400 determines whether Cresp 410 indicates a retry, as shown in the first three rows of Table III (block 504). If so, the process returns to block 502, which shows host 400 reissuing request 402 for the FC operation on the system fabric. If host 400 determines at block 504 that Cresp 410 for request 402 is not a retry, then in the embodiment of Table III, the coherency result is HPC_Success (a positive determination at block 505; the fourth row of Table III), Success_with_cleanup (Success_CU) (a positive determination at block 506; the fifth and sixth rows of Table III), or Success (a negative determination at both blocks 505 and 506; the seventh row of Table III). If Cresp 410 is Success (as indicated by the negative determinations at both blocks 505 and 506), then no cached copy of the target cache line exists in data processing system 100. As a result, the flush or cleanup operation completes successfully, and Figure 5 The process ends at 520 .

[0064] However, if Cresp 410 indicates Success_CU, then Cresp 410 indicates that one or more caches may maintain a copy of the target cache line other than in a dirty HPC state, and indicates that no caches maintain copies of the target cache line in the HPC state or that, in response to request 402, the write of the target cache line back to system memory 108 is completed with an HPC_Ack Presp indication and the coherence ownership of the target cache line is transferred to the host 400 at Cresp. Therefore, the host 400 opens the protection window 413 and begins protecting the target address by causing any conflicting snoop requests to receive a heavyweight retry Presp (block 508). In addition, if the FC operation is a flush or AMO operation, the host 400 issues a clean command (e.g., a BK or BK_Flush command from Table II) on the system fabric to invalidate any shared cached copies of the target memory block (block 510). After block 510, Figure 5The process proceeds to block 512, which shows a determination of whether Cresp 410 for the flush command issued at block 510 indicates success. If not, the process returns to block 510, which indicates that the host 400 reissues the flush command. Upon receiving Cresp 410 indicating success for the flush command issued at block 510, the host 400 closes the protection window 413 and thus ends protection of the target address of the request for the FC operation (block 514). Thereafter, Figure 5 The process ends at block 520 .

[0065] If Cresp 410 for the FC operation is HPC_Success, Cresp 410 indicates that the previously dirty HPC cache has completed the processing necessary for the given class of FC operation (e.g., writing the target cache line back to system memory 108 and updating its directory), and that no cache holds a copy of the target cache line in a shared coherence state or that the FC operation does not interact with the shared copy of the target cache line, or both. Because there are no cached copies of the target cache line present in the data processing system 100 or those that do exist are not affected by the FC operation, the host 400 does not issue a clean command, and Figure 5 The process ends at block 520. It should be noted that the Cresp for HPC_Success is not received for the initial request for the FC operation, but is received only after at least one retry, as described below. Figure 6 Block 602 and blocks 630 to 632 are discussed further herein.

[0066] Now refer to Figure 6 , which is a high-level logical flow chart of an exemplary process by which an HPC cache handles a snoop request for an FC memory access operation, according to one embodiment. Figure 7 The timing diagram 700 is used to describe Figure 6 Flowchart of the process.

[0067] Figure 6The process depicted in FIG6 begins at block 600 and proceeds to block 602, which illustrates that the L2 cache memory 230, which maintains the target cache line of the FC memory access operation in a dirty HPC coherence state (e.g., M or T coherence state), snoops a request for a FC memory access operation from the local interconnect 114. The FC memory access operation may be, for example, a DCBF, DCBST, or AMO operation as previously described, or any other memory-modifying FC operation that requires modified cached data to be written back to the system memory 108. In response to snooping the request for the FC memory access operation, the L2 cache memory 230 allocates the SN engine 311 to service the FC memory access operation and sets the SN engine 311 to a busy state, causing the SN engine 311 to begin protecting the target real address specified by the request. Figure 7 The transition of the SN engine 311 from the idle state to the busy state, where the SN engine is assigned to service the request for the FC memory access operation, is shown at reference numeral 702. In addition, the L2 cache memory 230 provides a heavyweight retry Presp to the request for the FC memory access operation because the modified data from the target cache line has not yet been written to the system memory 108.

[0068] When the SN engine 311 is in the busy state, the SN engine 311 performs normal processing for the snooped request (block 604). This normal processing includes writing the modified data of the target cache line back to the associated system memory 108 via the system structure and, when the update of the system memory 108 is complete, invalidating the target cache line in the local directory 308 if required by the FC request 402. In addition, as further shown in block 604, when the SN engine 311 is in the busy state, the L2 cache 230 provides a heavyweight retry partial response to any snooped request requesting access to the target cache line, such as Figure 7 704. The heavyweight retry partial response causes the associated instance of response logic 218 to form a RetryCresp 410, which forces the host of the conflicting request to reissue its request.

[0069] In some embodiments, the SN engine 311 assigned to the request for the FC memory access operation automatically sets the REF (referee) mode indicator (eg, Figure 6 Box 608 and Figure 7 706). Figure 6In other embodiments represented by optional block 606, the SN engine 311 conditionally sets the REF mode indicator at block 608 only when a conflicting request for a non-FC operation is snooped by the L2 cache 230 while the SN engine 311 is busy processing a request for an FC memory access operation. After block 608, or if optional block 606 is implemented, after determining that no conflicting non-FC request is snooped, it is determined at block 610 whether the SN engine 311 has completed processing the snooped FC request. If not, Figure 6 The process returns to the already described block 604. However, if it is determined that the processing of the snooped FC request by the SN engine 311 is completed, such as Figure 7 As shown in the reference numeral 708, Figure 6 The process proceeds from box 610 to box 612.

[0070] Block 612 shows that after completing the processing of its FC operation, the SN engine 311 determines whether the REF mode indicator is set. If not, the SN engine 311 returns to the idle state, as shown in FIG. Figure 6 Box 614 and Figure 7 As shown in the reference numeral 710 in FIG. After block 614, Figure 6 The process ends at block 616. Returning to block 612, if the SN engine 311 determines that the REF mode indicator is set, the SN engine 311 does not return to the idle state upon completion of processing the request for the FC operation, but enters REF (referee) mode to extend its protection of the target cache line, such as Figure 6 Box 620 and Figure 7 As shown in the figure mark 712, in one embodiment, in conjunction with entering the REF mode, the SN engine 311 also starts a REF mode timer.

[0071] After block 620, the processing of the SN engine 311 enters a processing loop in which the SN engine 311 monitors the expiration of the REF mode timer (block 640) and snoops requests for the same class of FC operations (e.g., clean, flush, AMO, etc.) (block 630). While in this processing loop, the SN engine 311 monitors the system architecture for any conflicting operations that target the same cache line as the earlier snooped FC request but are not in the same class of FC operations, such as Figure 6 Box 622 and Figure 7 In response to detecting any such conflicting requests, the SN engine 311 provides a heavyweight retry Presp to the conflicting non-FC request, such as Figure 6 As shown in the box 624. This heavyweight retry Presp will cause the relevant instance of the response logic 218 to issue a retry Cresp, as described above. Figure 5and discussed in Table III of FIG. 5 and in block 504. Thereafter, the process passes to block 640, which will be described below.

[0072] During the processing cycle, the SN engine 311 also monitors the system structure for any conflicting FC operations that target the same cache line as the earlier snooped FC request and are in the same class of FC operations (e.g., clean, flush, AMO, etc.), such as Figure 6 Box 630 and Figure 7 716. The conflicting FC operations may be issued by the same host 400 that issued the earlier FC request or by a different host. In response to detecting any such conflicting FC request, the SN engine 311 provides an HPC_Ack partial response to the conflicting FC request, such as Figure 6 This HPC_Ack partial response will cause the generation of HPC_Success Cresp (see, for example, Table III). In response to receiving the HPC_Success Cresp (block 634), Figure 6 The process passes to block 650, which is described below.

[0073] Block 640 depicts the SN engine 311 determining whether a timeout for REF mode has occurred by referring to the REF mode timer. In various embodiments, the timeout may occur at a static, predetermined timer value, or alternatively, at a dynamic value determined based on, for example, the number of conflicting FC and / or non-FC operations received during the period in which the SN engine 311 was in REF mode. If not, then Figure 6 The process returns to block 622, which has already been described. In response to determining at block 640 that the REF mode has timed out, the process proceeds to block 650, which shows the SN engine 311 exiting the REF mode, as shown. Figure 7 As shown by reference numeral 718, the SN engine 311 thus ends its protection of the target cache line and returns to the idle state ( Figure 6 Box 614 and Figure 7 720). Thereafter, Figure 6 The process ends at box 616.

[0074] Those skilled in the art will understand that Figure 6A technique is disclosed in which an HPC snooper temporarily enters a REF mode, wherein the HPC snooper extends coherency protection for a memory block that is a target of a request for an FC memory access operation in an interval between the end of a flush / scrub activity performed by the HPC snooper and the end of a subsequent FC memory access operation (e.g., Cresp), wherein the subsequent FC memory access operation is of the same class and specifies the same target address. This extended protection of the target cache line ensures that no further HPCs are formed for the target cache line until the FC memory access operation is guaranteed to succeed.

[0075] Now refer to Figure 8 , depicts a high-level logical flow diagram of an exemplary process by which a cache that maintains a non-HPC shared copy of a target cache of a snooped flush-type request (e.g., DCBF or AMO) processes the request, according to one embodiment. It should be noted that a cache that maintains a shared copy of a target cache of a clean (e.g., DCBST) request ignores the clean request.

[0076] Figure 8 The process begins at block 800 and then proceeds to block 802, which shows that the L2 cache 230, which holds the target cache line of a refresh-type request, snoops an initial request for a refresh-type operation (e.g., DCBF or AMO) or an associated flush command (e.g., BK or BK_FLUSH). In response to snooping the initial request or flush command, the L2 cache 230 provides a lightweight retry response. In addition, in response to the initial request, the L2 cache 230 assigns a SN engine 311 to process the initial request. The assigned SN engine 311 transitions from an idle state to a busy state and begins protecting the target cache line.

[0077] At block 804, the SN engine 311 assigned to process the request snooped at block 802 performs normal processing of the initial request or clean command by invalidating the target cache line in the local directory 308. As further shown at block 804, while the SN engine 311 is busy, the L2 cache 230 provides a lightweight retry partial response to any snooped request requesting access to the target cache line. At block 806, it is determined whether the processing of the snooped request by the SN engine 311 is complete. If not, then Figure 8 The process returns to the already described block 804. However, if it is determined that the SN machine 311 is finished processing the snooped request, the SN machine 311 returns to the idle state (block 808), and Figure 7 The processing ends at box 810.

[0078] Now refer to Figure 9, depicts a block diagram of an exemplary design flow 900 used, for example, in semiconductor IC logic design, simulation, testing, layout, and manufacturing. The design flow 900 includes a method for processing a design structure or device to generate the above-mentioned and Figures 1 to 3 The process, machine, and / or mechanism for producing a logically or other functionally equivalent representation of a design structure and / or device shown in the design flow 900 may be encoded on a machine-readable transmission or storage medium to include data and / or instructions that, when executed or otherwise processed on a data processing system, generate a logically, structurally, mechanically, or other functionally equivalent representation of a hardware component, circuit, device, or system. A machine includes, but is not limited to, any machine used in the IC design process, such as for designing, manufacturing, or simulating circuits, components, devices, or systems. For example, a machine may include: a photolithography machine, a machine and / or device for generating masks (e.g., an electron beam writer), a computer or device for simulating a design structure, any apparatus for a manufacturing or testing process, or any machine for programming a functionally equivalent representation of a design structure into any medium (e.g., a machine for programming a programmable gate array).

[0079] The design flow 900 may vary depending on the type of representation being designed. For example, the design flow 900 for building an application-specific IC (ASIC) may be different from the design flow 900 for designing a standard component or different from the design flow 900 for instantiating a design into a programmable array, such as a programmable gate array (PGA) or a field programmable gate array (FPGA) provided by Altera Corporation or Xilinx, Inc.

[0080] Figure 9 A plurality of such design structures are shown, including an input design structure 920 that is preferably processed by the design process 900. The design structure 920 may be a logic simulation design structure that is generated and processed by the design process 900 to produce a logically equivalent functional representation of a hardware device. The design structure 920 may also or alternatively include data and / or program instructions that, when processed by the design process 900, generate a functional representation of the physical structure of the hardware device. Whether representing functional and / or structural design features, the design structure 920 may be generated using electronic computer-aided design (ECAD), such as implemented by a core developer / designer. When encoded on a machine-readable data transmission, gate array, or storage medium, the design structure 920 may be accessed and processed by one or more hardware and / or software modules within the design process 900 to simulate or otherwise functionally represent a device such as a hardware device. Figures 1 to 3, electronic components, circuits, electronic or logic modules, devices, apparatus, or systems such as those shown in . Thus, design structure 920 may include files or other data structures, including human and / or machine readable source code, compiled structures, and computer executable code structures, which, when processed by a design or simulation data processing system, functionally simulate or otherwise represent a circuit or other level of hardware logic design. Such data structures may include hardware description language (HDL) design entities or other data structures that conform to and / or are compatible with low-level HDL design languages ​​such as Verilog and VHDL and / or high-level design languages ​​such as C or C++.

[0081] The design process 900 preferably employs and incorporates hardware and / or software modules for synthesizing, converting, or otherwise processing data related to Figures 1 to 3 , a design / simulation function equivalent to the components, circuits, devices, or logic structures shown in , is used to generate a netlist 990, which may include a design structure such as design structure 920. Netlist 990 may include, for example, a compiled or otherwise processed data structure that represents a list of wires, discrete components, logic gates, control circuits, I / O devices, models, etc. that describe connections to other elements and circuits in the integrated circuit design. Netlist 990 may be synthesized using an iterative process in which netlist 990 is resynthesized one or more times, depending on the design specifications and parameters of the device. As with other design structure types described herein, netlist 990 may be recorded on a machine-readable storage medium or programmed into a programmable gate array. The medium may be a non-volatile storage medium, such as a magnetic or optical disk drive, a programmable gate array, a compact flash memory, or other flash memory. Additionally or alternatively, the medium may be system or cache memory, or buffer space.

[0082] The design process 900 may include hardware and software modules for processing various input data structure types, including a netlist 990. Such data structure types may, for example, reside within a library element 930 and include a set of commonly used components, circuits, and devices, including models, layouts, and symbolic representations for a given manufacturing technology (e.g., different technology nodes, 32nm, 45nm, 90nm, etc.). Data structure types may also include design specifications 940, characterization data 950, verification data 960, design rules 970, and test data files 995, which may include input test patterns, output test results, and other test information. The design process 900 may also include, for example, standard mechanical design processes such as stress analysis, thermal analysis, mechanical event simulation, process simulation for operations such as casting, molding, and compression molding, etc. Those skilled in the art of mechanical design will understand the range of possible mechanical design tools and applications used in the design process 900 without departing from the scope and spirit of the present invention. The design process 900 may also include modules for performing standard circuit design processes, such as timing analysis, verification, design rule checking, placement and routing operations, etc.

[0083] The design process 900 employs and incorporates logical and physical design tools, such as HDL compilers and simulation model building tools, to process the design structure 920 and some or all of the depicted supporting data structures along with any additional mechanical design or data, if applicable, to generate a second design structure 990. The design structure 990 resides on a storage medium or programmable gate array in a data format for data exchange of mechanical devices and structures (e.g., information stored in IGES, DXF, Parastoll XT, JT, DRG, or any other suitable format for storing or presenting such mechanical design structures). Similar to the design structure 920, the design structure 990 preferably includes one or more files, data structures, or other computer-encoded data or instructions that reside on a transmission or data storage medium and, when processed by the ECAD system, generate a form of the design that is logically or otherwise functionally equivalent. Figures 1 to 3 In one embodiment, the design structure 990 may include functionally simulating Figures 1 to 3 A compiled, executable HDL simulation model of the device shown in .

[0084] Design structure 990 may also be in a data format and / or symbol data format for exchanging layout data of integrated circuits (e.g., information stored in GDSII (GDS2), GL1, OASIS, a map file, or any other suitable format for storing such a design data structure). Design structure 990 may include information such as symbol data, a map file, a test data file, a design content file, manufacturing data, layout parameters, wires, metal layers, vias, shapes, data for routing through a production line, and information for a manufacturer or other designer / developer to produce the integrated circuits as described above and as Figures 1 to 3 Any other data required for the device or structure shown, design structure 990 can then proceed to stage 995, where, for example, design structure 990 is: taped out, shipped to manufacturing, shipped to a mask shop, sent to another design house, sent back to a customer, etc.

[0085] As described above, in at least one embodiment, the cache memory includes a data array, a directory of contents of the data array specifying consistency state information, and snoop logic that handles snooping operations from the system structure by referencing the data array and the directory. The snoop logic, in response to a request to snoop a first refresh / clean memory access operation specifying a target address on the system structure, determines whether the cache memory has consistency ownership of the target address. Based on determining that the cache memory has consistency ownership of the target address, the snoop logic services the request and thereafter enters a referee mode. When in referee mode, the snoop logic protects the memory block identified by the target address from conflicting memory access requests from multiple processor cores until the second refresh / clean memory access operation specifying the target address is completed.

[0086] While various embodiments have been shown and described in detail, those skilled in the art will understand that various changes in form and details may be made therein without departing from the spirit and scope of the appended claims, and all such alternative implementations are within the scope of the appended claims.

[0087] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention.In this regard, each frame in the flow chart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing the specified logical function.In some alternative embodiments, the function mentioned in the frame may not occur in the order mentioned in the figure.For example, the two frames shown in succession can actually be performed substantially concurrently, or these frames can sometimes be performed in reverse order, depending on the function involved.It will also be noted that the combination of the frames in each frame of the block diagram and / or the flow chart and the block diagram and / or the flow chart can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special-purpose hardware and computer instructions.

[0088] Although various aspects have been described with respect to a computer system executing program code that directs the functions of the present invention, it should be understood that the present invention may alternatively be implemented as a program product including a computer-readable storage device storing program code that can be processed by a processor of a data processing system to cause the data processing system to perform the described functions. The computer-readable storage device may include volatile or non-volatile memory, optical or magnetic disks, and the like, but excludes non-statutory subject matter such as propagating signals themselves, transmission media themselves, and energy forms themselves.

[0089] As an example, a program product may include data and / or instructions that, when executed on a data processing system or otherwise processed, generate a logically, structurally, or otherwise functionally equivalent representation (including a simulation model) of a hardware component, circuit, device, or system disclosed herein. Such data and / or instructions may include hardware description language (HDL) design entities or other data structures that conform to and / or are compatible with low-level HDL design languages ​​such as Verilog and VHDL and / or high-level design languages ​​such as C or C++. In addition, the data and / or instructions may also be in a data format and / or symbolic data format for exchanging layout data of integrated circuits (e.g., information stored in GDSII (GDS2), GL1, OASIS, a map file, or any other suitable format for storing such design data structures).

Claims

1. A cache memory of an associated processor core of a plurality of processor cores in a multiprocessor data processing system, the multiprocessor data processing system comprising a system structure, the system structure communicatively coupling the cache memory and a memory controller of a system memory to receive operations on the system structure, the cache memory comprising: Data array; a directory of contents of the data array, wherein the directory includes consistency state information; as well as and snoop logic that processes an operation snooped from a system structure by referring to the data array and the directory, wherein the snoop logic performs the following operations in response to a request for a first flush / clean memory access operation of a processor core of a plurality of processor cores snooped on the system structure to a specified target address: determining whether the cache memory has coherent ownership of the target address; based on determining that the cache memory has coherent ownership of the target address, servicing the request and thereafter entering an adjudication mode; as well as When in arbitration mode, a memory block identified by the target address is protected from conflicting memory access requests by multiple processor cores until a second refresh / scrub memory access operation specifying the target address is completed.

2. The cache memory according to claim 1, wherein: The request for the refresh or clean operation is a first request; and The snoop logic is configured to enter the arbitration mode based on snooping a conflicting second request after snooping the first request and before the snoop logic completes processing of the first request. 3 . The cache memory of claim 1 , wherein the snoop logic is configured to protect the memory block from conflicting memory access requests by issuing a retry coherency response to the conflicting memory access requests.

4. The cache memory according to claim 1, wherein: When in the arbitration mode, the snoop logic is configured to provide a first consistency response to conflicting requests for refresh / clean memory access operations of the same type as the first refresh / clean memory access operation, and to provide a different second consistency response to other types of conflicting requests.

5. The cache memory of claim 1, wherein the snoop logic detects a timeout condition while in the arbitration mode and exits the arbitration mode in response to detecting the timeout condition.

6. The cache memory of claim 1, wherein the cache memory enters the arbitration mode based solely on coherence state information in the directory, the coherence state information indicating coherence ownership of the modified cache line associated with the target address.

7. A processing device comprising: The cache memory according to claim 1; as well as At least one auxiliary processor core is coupled to the cache memory.

8. A data processing system comprising: System architecture; as well as The plurality of processing devices of claim 7, all coupled to the system architecture.

9. A method of performing data processing in a multi-processor data processing system, the multi-processor data processing system comprising a cache memory of an associated processor core among a plurality of processor cores in the multi-processor data processing system, the multi-processor data processing system comprising a system structure, the system structure communicatively coupling the cache memory and a memory controller of a system memory to receive an operation on the system structure, the method comprising: The cache memory snoops on the system structure a request for a first flush / clean memory access operation of a processor core of the plurality of processor cores specifying a target address; Based on snooping the request, the cache memory determines whether the cache memory has coherent ownership of the target address; Based on determining that the cache memory has coherent ownership of the target address, the cache memory services the request and thereafter enters an adjudication mode; as well as When in the arbitration mode, the cache memory protects the memory block identified by the target address from conflicting memory access requests of the plurality of processor cores until a second flush / scrub memory access operation specifying the target address ends.

10. The method according to claim 9, wherein: The request for the flush or clean operation is the first request; and Entering the arbitration mode includes entering the arbitration mode based on snooping a conflicting second request after snooping the first request and before the snoop logic completes processing of the first request.

11. The method of claim 9, wherein the protecting comprises the cache memory protecting a memory block from conflicting memory access requests by issuing a retry coherency response to the conflicting memory access requests.

12. The method according to claim 9 further includes, when in the arbitration mode, the cache memory providing a first consistency response to conflicting requests for refresh / clean memory access operations of the same type as the first refresh / clean memory access operation, and providing a different second consistency response to other types of conflicting requests.

13. The method of claim 9, further comprising, while in the referee mode, the cache memory detecting a timeout condition, and exiting the referee mode in response to detecting the timeout condition.

14. The method according to claim 9, wherein: The cache memory includes a data array and a directory of contents of the data array, the directory including coherence state information, and wherein entering the umpire mode includes the cache memory entering the umpire mode based solely on the coherence state information, the coherence state information indicating coherence ownership of a modified cache line associated with the target address.

15. An apparatus tangibly embodied in a machine-readable storage device for designing, manufacturing, or testing an integrated circuit, the apparatus comprising: Processing unit, comprising: Multiple processor cores; Cache memory, including: Data array; a directory of contents of the data array, wherein the directory includes coherence state information; and snoop logic, the snoop logic processing an operation snooped from a system structure by referring to the data array and the directory, wherein the snoop logic performs the following operations in response to a request for a first flush / clean memory access operation of a processor core of the plurality of processor cores snooped on the system structure to a designated target address: determining whether the cache memory has coherent ownership of the target address; Based on determining that the cache memory has coherent ownership of the target address, servicing the request and thereafter entering an arbitration mode; and When in the arbitration mode, the memory block identified by the target address is protected from conflicting memory access requests by the plurality of processor cores until a second refresh / scrub memory access operation specifying the target address is completed.

16. The device according to claim 15, wherein: The request for the flush or clean operation is the first request; and The snoop logic is configured to enter the arbitration mode based on snooping a conflicting second request after snooping the first request and before the snoop logic completes processing of the first request. 17 . The apparatus of claim 15 , wherein the snoop logic is configured to protect a memory block from conflicting memory access requests by issuing a retry coherency response to the conflicting memory access requests.

18. The apparatus of claim 15, wherein: When in the arbitration mode, the snoop logic is configured to provide a first consistency response to conflicting requests for refresh / clean memory access operations of the same type as the first refresh / clean memory access operation, and to provide a different second consistency response to other types of conflicting requests.

19. The apparatus of claim 15, wherein the snoop logic detects a timeout condition while in the adjudication mode and exits the adjudication mode in response to detecting the timeout condition.

20. The apparatus of claim 15, wherein the cache memory enters the arbitration mode based solely on coherence state information in the directory, the coherence state information indicating coherence ownership of the modified cache line associated with the target address.

Images