Data cache storage block share requirements

Abstract

Method for processing data in a data processing system (100) comprising a processor core (202) supported by higher-level and lower-level cache memory (204; 230; 232), wherein the method comprises: Automatic insertion of a release instruction by a compiler (500) into program code executed by the processor core (202), wherein the automatic insertion includes the compiler (500) automatically inserting the release instruction into the program code in response to a detection of the end of processing a data record, Execution of the release instruction by the processor core (202) upon completion of processing a data record that includes a target cache memory line and a multitude of other cache memory lines to assist in clearing the data record from the sublevel cache memory (230; 232), In response to the execution of the release instruction in the processor core (202), a release request is sent from the processor core (202) to the sublevel cache memory (230; 232), the release request specifying a destination address that is associated with the destination cache memory row; In response to receiving the release request in the child level cache (230; 232), determine whether the target address finds a match in the child level cache (230; 232); and In response to a finding that the target address has a match in the child level cache (230; 232), the target cache row is retained in a data array (302) of the child level cache (230; 232), and a replacement order field (416) is updated in a directory (308) of the child level cache (230; 232), so that the target cache row is more likely to be cleared from the child level cache (230; 232) in response to a subsequent cache mismatch in a congruence class that includes the target cache row.

Description

BACKGROUND OF THE INVENTION 1. Technical field:

[0001] The present invention relates generally to data processing and in particular to processing requests for releasing a data cache memory block in a cache memory of a data processing system. 2. Description of the related technique:

[0002] A conventional multiprocessor (MP) computer system, such as a server computer system, contains several processing units, all connected by a system interface that typically includes one or more address, data, and control buses. Connected to this interface is system memory, which represents the lowest level of volatile memory in the multiprocessor computer system and is generally accessible to all processing units for read and write operations. To reduce latency when accessing instructions and data located in system memory, each processing unit is typically further supported by a corresponding multi-level cache hierarchy, with each lower level generally exhibiting progressively longer access latency.Accordingly, a level one (L1) cache generally has a shorter access latency than a level two (L2) cache, which in turn has a shorter latency than a level three (L3) cache.

[0003] To balance competing design considerations such as power consumption, size, access latency, and hit rates, many MP systems implement set-associative caches that group cache entries into congruence classes. Each congruence class contains multiple entries for storing cache rows that share a common address index. The removal (purge) of cache rows from the entries in each congruence class is controlled by a replacement strategy, which is preferentially chosen to remove the cache row from the congruence class least likely to be accessed again. Conventional replacement strategies include LRU (least-recently used) and round-robin.

[0004] For some workloads, the replacement strategy implemented by the cache hardware is supplemented by additional software management of the cache memory(s). For example, in some cases, a programmer or compiler can insert explicit instructions into an application program to cause the cache hierarchy to invalidate specific cache memory lines or write specific cache memory lines back to system memory. Examples of cache memory management instructions from the PowerPC instruction set architecture are listed below in Table I. Table I Mnemonic PowerPC term Command name DCBF Write back data cache row DCBI Invalidate data cache row DCBZ Overwrite data cache row with zeros ICBI Invalidate command cache line

[0005] In some cases, explicit cache management commands can lead to inefficiencies in application execution, for example, by invalidating a cache line or writing it back to system memory before accessing it again. In such cases, accessing the cache line after software-controlled invalidation or writing back results in significantly increased access latency, as the cache line must be retrieved again from system memory, which can have an access latency two orders of magnitude longer than that of the higher levels of the cache hierarchy.

[0006] US Patent 6,766,419 B1 describes program instructions that enable software management of a processor cache. These instructions allow a software developer to provide software release hints that identify data unlikely to be used during subsequent program execution. The instructions then allow a processor to clear the identified data from the cache before other data candidates likely to be used during further program execution. SUMMARY OF THE INVENTION

[0007] In at least one embodiment, a data processing system includes a processor core supported by higher-level and lower-level cache memory. In response to the execution of a release instruction in the processor core, a release request is sent from the processor core to the lower-level cache memory, the release request specifying a destination address corresponding to a target cache memory row. Upon receiving the release request in the lower-level cache memory, it is determined whether the destination address is found in the lower-level cache memory.In response to a finding that the target address has a match in the child level cache, the target cache row is retained in a data array of the child level cache, and a replacement order field in a directory of the child level cache is updated so that the target cache row is more likely to be purged from the child level cache in response to a subsequent cache mismatch in a congruence class that includes the target cache row. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is an overview block diagram of an exemplary data processing system according to one embodiment; Fig. 2A is an overview block diagram of a processing unit of Fig. 1; Fig.Figure 2B is a more detailed block diagram of an exemplary embodiment of a processor core and an associated cache memory hierarchy of Fig. 2A; Fig. Figure 3 illustrates an exemplary embodiment of a subordinate level cache memory of Fig. 2B; Fig. Figure 4 represents an exemplary embodiment of a cache directory of a subordinate level cache; Fig. Figure 5 illustrates the operation of a compiler according to one embodiment; Fig. Figure 6 is an overview plan of a logical sequence of an exemplary procedure for compiling source code to generate object code according to an embodiment; Fig. Figure 7 is an overview diagram of a logical sequence of an exemplary procedure by which a processor core executes a release instruction, according to one embodiment; Fig.Figure 8 is an overview plan of a logical sequence of an exemplary procedure by which a subordinate level cache memory processes a release request, according to one embodiment; Fig. Figure 9 is an overview diagram of the logical flow of an exemplary procedure by which a subordinate level cache memory serves a memory access request, according to one embodiment; and Fig. Figure 10 is an overview plan of a logical sequence of an exemplary procedure by which a subordinate level cache memory serves a cast-in request, according to one embodiment. DETAILED DESCRIPTION OF ILLUSTRATIVE FORM OF EXECUTION

[0008] With reference to the characters and in particular with reference to Fig.Figure 1 illustrates an overview block diagram of an exemplary embodiment of a multiprocessor data processing system according to the present invention. As shown, a data processing system 100 includes several processing nodes 102a, 102b for processing data and instructions. The processing nodes 102a, 102b are connected via a system connection 110 to transmit address, data, and control information. The system connection 110 can be implemented, for example, as a bus connection, a switch connection, or a hybrid connection.

[0009] In the illustrated embodiment, each processing node 102 is implemented as a multi-chip module (MCM) containing four processing units 104a to 104d, each preferably implemented as a corresponding integrated circuit. The processing units 104a to 104d within each processing node 102 are connected for data exchange via a local connection 114, which, like the system connection 110, can be implemented with one or more buses and / or switches. The local connections 114 and the system connection 110 together form a connection structure that preferably supports the simultaneous data exchange of operations with different transmission domains. For example, the connection structure preferably supports the simultaneous data exchange of operations whose scope is limited to a single processing node 102 and of operations that are transmitted to multiple processing nodes 102.

[0010] The units connected to each local connection 114 include not only the processing units 104, but also one or more system memories 108a to 108d. Data and instructions located in the system memories 108 can generally be accessed by a processor core ( Fig. 2A) can be accessed and modified by any processing unit 104 in any processing node 102 of the data processing system 100. In alternative embodiments of the invention, one or more system memories 108 can be connected to the system connection 110 instead of a local connection 114.

[0011] It is apparent to those skilled in the art that the data processing system 100 may include many additional components not illustrated, such as peripheral units, connecting bridges, non-volatile memory, ports for network or connected units, etc. Since such additional components are not necessary for understanding the present invention, they are not shown in the illustrations. Fig. Figure 1 illustrates this and is discussed further herein. It is also understood, however, that the improvements provided by the present invention are applicable to data processing systems with various architectures and are in no way limited to the generalized data processing system architecture described in Figure 1. Fig. 1 is illustrated.

[0012] It will now Fig.Reference is made to Figure 2A, which presents a more detailed block diagram of an exemplary processing unit 104 according to the present invention. In the illustrated embodiment, each processing unit 104 includes multiple instances of a processor core and an associated cache memory hierarchy, collectively identified by reference numeral 200. In the illustrated embodiment, each processing unit 104 also includes an integrated memory controller (IMC) 206, which controls read and write access to one or more of the system memories 108a to 108d within its processing node 102 in response to requests received from processor cores and operations detected by snooping in the local connection 114.

[0013] Furthermore, with reference to Fig.2A Each processing unit 104 also includes an instance of a coherence management logic 210, which implements a section of the distributed coherence signaling mechanism based on snooping, maintaining cache memory coherence within the data processing system 100. Furthermore, each processing unit 104 includes an instance of a connection logic 212 for selectively forwarding data transmissions between its local connection 114 and the system connection 110. Finally, each processing unit 104 includes an integrated I / O (input / output) control unit 214, which supports the connection of one or more I / O units, such as an I / O unit 216. The I / O control unit 214 can execute operations on the local connection 114 and / or the system connection 110 in response to requests from the I / O control unit 216.

[0014] It will now Fig.Reference is made to 2B, which provides a more detailed block diagram of an exemplary embodiment of a processor core and an associated cache memory hierarchy 200 of Fig. 2A. The processor core 202 includes circuitry for processing instructions and data. In the illustrated embodiment, this circuitry includes an instruction sequencing unit (ISU) 201, which retrieves instructions from the memory hierarchy and orders the instructions for execution, and one or more execution units (ISUs) 203, which execute instructions received from the ISU 203. In the illustrated embodiment, the execution units 203 include a load-store unit (LSU) 205, which executes memory access instructions and cache management instructions to calculate target addresses and generate corresponding memory access and cache management requests that specify the target addresses.

[0015] The operation of the processor core 202 is supported by a cache memory hierarchy that implements a weakly ordered memory architecture, which means that the cache memory hierarchy can generally process memory requests received from the connected processor core 202 out of order with respect to the program order of the associated memory instructions executed by the processor core 202, and only enforces an ordering between groups of memory requests that are separated by a locking operation.The cache hierarchy includes a level one (L1) store-through cache 204 within each processor core 202, a level two (L2) store-in cache 230 (which preferentially includes the L1 cache 204), and an L3 lookaside cache 232, which acts as a selection cache for the L2 cache 230 and is accordingly filled with cache memory rows that are cleared from the L2 cache 230. Unlike many conventional selection cache arrangements, the contents of the L3 cache 232 do not exclude the contents of the L2 cache 230, meaning that a given block of memory can be held in both the L2 cache 230 and the L3 cache 232 simultaneously.

[0016] The L3 cache memory 232 further includes at least one and preferably a plurality of Snoop (SN) machine(s) 236 and at least one and preferably a plurality of write-inject (WI) machine(s) 238 (see Fig.2B). As discussed further below, the SN(s) 236 and WI(s) 238 process the cast-in of cache memory lines into the L3 cache memory 232 in response to lateral cast-out (LCO) instructions received from other L3 cache memories 232. In the described embodiment, the SN(s) 236 is / are used to process cast-in operations that do not require data shifting and therefore preferably do not include incoming data management instructions, whereas the WI(s) 238 is / are used to process LCO instructions that do require data shifting and therefore include incoming data management instructions (making it / them more computationally expensive than the SN(s) 236). The WI(s) 238 also process the injection of cache memory lines into the L3 cache memory 232 by the I / O units 216.

[0017] Fig.Figure 2B also illustrates an exemplary flow of requests, data, and coherence data exchange within the cache memory hierarchy of the processor core 202. In the arrangement shown, dashed lines represent the flow of requests and coherence instructions, and solid lines represent a data flow.

[0018] As shown, the processor core 202 transmits load requests 240 to and receives load data 242 from the L2 cache 230. The processor core 202 also transmits memory requests 244 and associated memory data 246 to a capture logic 248, which captures the memory data belonging to multiple requests in a cache row of data and transmits the captured memory data 249 to the L2 cache 230 along with a captured memory request 247. Although shown separately for clarity, the capture logic 248 can be included in the processor core 202 and / or the L2 cache 230.

[0019] In response to a memory access request from the processor core 202, the L2 cache 230 assigns one of a variety of read-claim (RC) machines 231 to handle the memory access request. Handling the memory access request may involve the RC 231 of the L2 cache 230 issuing system coherence instructions 250 for compilation and / or transmission via the link structure to the coherence management logic 210. Fig.2A transmits. The RC 231 of the L2 cache memory 230 can also transmit write data 254 to the IMC 206 and / or the link logic 212, and it receives load data 252 from them. The RC 231 of the L2 cache memory 230 can also request load data from the L3 cache memory 232 via a load request 260 and receive load data 262 from the L3 cache memory 232. The L2 cache memory 230 further includes a variety of snoop (SN) machines 233 to handle memory access requests (e.g., read requests, read-with-intent requests, and delete requests) that have been detected in the link structure by snooping.

[0020] To remove a cache memory line from the L2 cache 230, the L2 cache 230 can issue a cast-in request to the L3 cache 232, which in turn receives the cache memory line as cast-in data 266. Similar to the L2 cache 230, the L3 cache 232 can interact with the IMCs 206 and / or caches in other cache hierarchies by issuing system coherence commands 270, receiving pre-access data 272 and / or cast-in data 273, and / or transferring write data 274.

[0021] Although the illustrated cache hierarchy includes only three cache levels, it is apparent to those skilled in the art that alternative embodiments may include additional levels (L4, L5, etc.) of an integrated or conversion cache on or off the chip, which may fully enclose, partially enclose, or not enclose the contents of the higher-level cache levels. Furthermore, each of the different levels of the cache hierarchy may be available only to a specific processor core 202 or may be shared by multiple processor cores 202. For example, in some implementations, the cache hierarchy includes an L2 cache 230 for each processor core 202, with several of the L2 caches 230 sharing a common L3 selection cache 232.

[0022] It will now Fig.3 Referenced, which illustrates an overview block diagram of an exemplary embodiment of one of the L2 cache memories 230. (The L3 cache memories 232 can be implemented similarly.) As shown, the L2 cache memory 230 includes a data array 302 and a directory 308 of the contents of the data array 302, embodiments of which are described in more detail below with reference to Fig.4. The L2 cache memory 230 also includes additional control logic (which, according to the prior art, is collectively referred to as the "cache memory control unit"), which, in the illustrated embodiment, includes several (e.g., 16) read request (RC) machines 231a to 231n for independently and simultaneously handling load (LD) and store (ST) requests received by the connected processor core 202. To handle remote memory access requests originating from processor cores 202 other than the connected processor core 202, the control logic of the L2 cache memory 230 includes several snoop (SN) machines 233a to 233m. Each snoop machine 233 can independently and simultaneously process a remote memory access request that was detected by "snooping" in the local connection 114.As can be seen, handling memory access requests by RC machines 312 may require replacing or invalidating memory blocks within the data array 302. Accordingly, the L2 cache memory includes 230 CO (castout) machines 310, which manage the removal and rewriting of memory blocks from the data array 302.

[0023] The control logic of the L2 cache 230 further includes an arbiter 305, which controls multiplexers M1 to M2 to manage the processing of local memory access and cache management requests received by the connected processor core 200, and remote requests detected by snooping on the local connection 114. Requests are forwarded to an allocation pipeline 306 according to the arbitration strategy implemented by the arbiter 305, where each request is processed with respect to directory 308 over a specified number of cycles.

[0024] The control logic of the L2 cache 230 also includes an RC queue (RCQ) 320 and a Castout Push Intervention (CPI) queue 318, each of which buffers data being inserted into or removed from the data array 302. The RC queue 320 contains a number of buffer entries, each corresponding to a specific RC machine 231, so that each allocated RC machine 231 retrieves data only from its named buffer entry. Similarly, the CPI queue 318 contains a number of buffer entries, each corresponding to a specific castout machine 310 and snoop machine 233, so that each allocated castout machine 310 and snoop machine 233 retrieves data only from its respective named CPI buffer entry.

[0025] Each RC machine 231 is also assigned one of several RC data (RCDAT) buffers 322 for temporarily storing a memory block read from the data array 302 and / or received from the local connection 114 via a reload bus 323. The RCDAT buffer 322 assigned to each RC machine 312 is preferably designed with connections and functionality that meet the memory access requirements that can be served by the associated RC machine 312. At least some of the RCDAT buffers 322 have an associated memory data multiplexer M4, which selects data bytes from its inputs for temporary storage in the RCDAT buffer 322 in response to selection signals (not illustrated) generated by the arbiter 305.

[0026] During operation, the connected processor core 202 receives processor memory requests within a store queue (STQ) 304. These requests include a transaction type (ttype), a real destination address, and memory data. The STQ 304 transfers the memory data via a data path 324 to the memory data multiplexer M4, and the memory type and destination address are passed to the multiplexer M1. The multiplexer M1 also receives processor load and release requests as inputs, sent by the processor core 202 via a load pipeline 325, and directory write requests sent by the RC machines 312.In response to selection signals (not illustrated) generated by arbiter 305, multiplexer M1 selects one of its input requests and forwards it to multiplexer M2, which additionally receives a remote request as input from local link 114 via a remote request path 326. Arbiter 305 schedules local and remote requests for processing and, based on this schedule, generates a sequence of selection signals 328. In response to the selection signals 328 generated by arbiter 305, multiplexer M2 selects either the local request received by multiplexer M1 or the remote request detected by snooping on local link 114 as the next request to be processed.

[0027] Furthermore, with reference to Fig.Step 3 places the request selected for processing by the arbiter 305 into the allocation pipeline 306 via the multiplexer M2. The allocation pipeline 306 is preferably implemented as a fixed-duration pipeline in which each of the several possible overlapping requests is processed over a predetermined number of clock cycles.

[0028] During the first processing cycle within allocation pipeline 306, a one-cycle directory read operation is performed. This operation uses the request's destination address to determine whether the destination address in directory 308 is a match or a miss. If the destination address is a match, the consistency status of the memory block within directory 308 is determined. The directory data, including a match / miss indicator and the memory block consistency status, is returned by directory 308 to allocation pipeline 306. As can be seen, generally no steps are initiated within an L2 cache 230 in response to a miss on a remote memory access request; such remote memory requests are accordingly dropped from allocation pipeline 306.In the event of a hit or miss in a local request or a hit in a remote storage access request, the L2 cache memory 230 serves the request, which may involve data exchange via the local connection 114 for requests that cannot be fully served within the processing unit 104.

[0029] At a predetermined point during the processing of a memory access request within allocation pipeline 306, the arbiter 305 transmits the request address to the data array 302 via an address and control path 330 to initiate a cache read operation on the target cache memory row specified by the target address, thereby generating additional power dissipation. The memory block read from the data array 302 is transferred via data path 342 to an error-correcting code (ECC) logic 344, which checks the memory block for errors and, if possible, corrects any detected errors. For processor load requests, the memory block is also transferred to the load data multiplexer M3 via data path 340 so that it can be forwarded to the connected processor core 202.

[0030] In the final cycle for processing a memory access request within Allocation Pipeline 306, Allocation Pipeline 306 makes an allocation decision based, for example, on (1) the presence of an address collision between the destination address and a previously received destination address currently being processed by a Castout Machine 310, a Snoop Machine 233, or an RC Machine 231, (2) the directory data, and (3) the availability of an RC Machine 231 or a Snoop Machine 233 to process the memory access request. If Allocation Pipeline 306 makes an allocation decision to allocate the memory access request, the memory access request is allocated by Allocation Pipeline 306 to an RC Machine 231 or a Snoop Machine 233. If the allocation of the memory access request fails, the error is reported to the requester (e.g.,The failed memory access request is reported to the local or remotely located processor core (202) by means of a retry response. The requester can then, if necessary, retry the failed memory access request.

[0031] While RC machine 231 is processing a local memory access request, it has a "Busy" state and is unavailable to handle another request. While RC machine 231 is in a "Busy" state, it can perform a directory write operation to update the corresponding entry in directory 308, if necessary. Additionally, RC machine 231 can perform a cache write operation to update the corresponding target cache row stored in data array 302. The directory write operation and the data array write operation can be scheduled by arbiter 305 during any interval in which allocation pipeline 306 is not already processing other requests according to the fixed schedule of directory read operations and data array read operations.When all operations for the respective local memory access request have been completed, the RC machine 312 returns to an "Unoccupied" state and is thus available to be allocated to handle another request.

[0032] It will now Fig.Reference is made to Figure 4, which presents a more detailed block diagram of an exemplary embodiment of the data array 302, the directory 308, and an L2 cache 230. (The data array of the L3 cache 232 can be implemented similarly.) In the illustrated embodiment, the data array has a record-associative organization and accordingly includes several paths 400a to 440n. Each path 400 contains several entries 402, each of which, in the illustrated embodiment, provides temporary storage for up to one complete memory block of data, e.g., 128 bytes. Each cache memory row or memory block of data is logically formed from several subunits 404 (in this example, four subunits of 32 bytes each), the size of which can correspond, for example, to the smallest permissible access to the system memories 108a to 108d.In some embodiments, the subunits 404 are individually accessible and can be temporarily stored in the data array 302.

[0033] As with conventional set-associative caches, memory positions in the system memory 108 are assigned to specific congruence classes within the data array 302 using predefined index bits within the (real) system memory addresses. The respective cache memory lines stored within the data array 302 are recorded in the cache memory directory 302, which contains a directory entry 410 for each cache memory line in the data array 302. As is evident to those skilled in the art, each directory entry 410 in the directory 308 has at least one identifier field 412, which identifies the respective cache memory line stored in the corresponding entry 402 of the data array 302 using an identifier segment of the corresponding real address, and a status field 414, which indicates the coherence status of the cache memory line (e.g.,according to the well-known MESI coherence protocol or a variant thereof) and a replacement sequence field 416.

[0034] The replacement order field 416 includes a chronology field 418, which specifies a relative replacement order for the cache memory row with respect to other cache memory rows in the same congruence class. Furthermore, in some (but not all) embodiments, the replacement order field 420 also includes a transient (T) field 420, which, if specified, indicates that the associated cache memory row was the target of a release request from the connected processor core 202 and should therefore be given preference when released from the cache memory hierarchy (e.g., as the longest unused element or some other preferred replacement order position).

[0035] It will now Fig.Reference is made to Figure 5, which illustrates a diagram of an exemplary data flow of a process by which a compiler compiles source code with an explicit release instruction that identifies a target cache memory row to be preferentially released from a cache memory hierarchy. In the depicted process, program code, such as a compiler 500, stored on a physical, machine-readable storage medium 502, such as a hard disk or main memory area, is executed in a data processing system (e.g., the data processing system 100 of Fig. 1) executed in such a way that it receives pre-processed code such as source code 502 or intermediate code, compiles the pre-processed code and outputs post-processed code such as object code 506.

[0036] As indicated, source code 504 includes an initialization instruction 510, which initializes a loop variable x of a processing loop 512 to an initial value (e.g., 0). Within processing loop 512, source code 504 includes a LOAD instruction 514, which specifies a record (e.g., a first array or database) to be loaded from a memory hierarchy, and one or more instructions, represented by a PROCESS instruction 516, which specify processing to be performed on the record. Processing loop 512 further includes an instruction 518, which increments the loop variable, and a BRANCH instruction 520, which causes processing loop 512 to iterate if the loop variable has not reached an end value (represented by a variable y).

[0037] It will now Fig.Reference is made to Figure 6, which presents an overview diagram of the logical flow of an exemplary process by which program code, such as the Compiler 500, processes pre-processed code, such as the Source Code 504, to produce post-processed code, such as the Object Code 506. As with the other logical flow diagrams presented herein, the illustrated operations are shown in a logical rather than a chronological order. Accordingly, in many cases, certain of the illustrated operations can be performed simultaneously and / or in a different order than that illustrated. The illustrated process can, for example, be performed as part of the code optimization operations of the Compiler 500.

[0038] As shown, the process begins at block 600 and then proceeds to blocks 602 through 604, which represent compiler 500 searching a section of source code 504 to detect the completion of data processing. In the example source code 504, the end of data processing might be detected, for instance, when the end of an iteration of processing loop 512 is reached. If compiler 500 fails to detect the end of data processing in the current section, the process moves to block 612, which illustrates compiler 500 determining whether its search through source code 504 is complete. If so, the process ends in Fig. Figure 6 illustrated the process at block 614. If, however, the compiler 500 determines at block 612 that its search through the source code 504 is not complete, the process returns to block 602, which has already been written.

[0039] Referring again to block 604, compiler 500, in response to detecting the end of processing a data record, inserts a deallocate instruction (referred to here as a Data Cache Block Deallocate (DCDB)) into object code 506 for each cache row in the data record whose processing is complete. Following block 610, the process proceeds to block 612, which has already been described.

[0040] Now again on Fig. 5. Referring to this, the exemplary section of object code 506, which is in Fig.As shown in block 5, an initial load sequence 530, consisting of several load (LD) instructions, is generated by the compiler 500 to implement the first iteration of the LOAD instruction 514. As indicated, the load sequence 530 loads the n+1 elements of the dataset Dataset_0 from the system memory 108 into the registers and cache memory hierarchy of a processor core 202. Following the load sequence 530, the compiler 532 has included one or more instructions 532 in the object code 506, implementing the processing represented by the PROCESS instruction 516. As described with reference to block 610, the compiler 500 then inserts a release sequence 534 into the object code 506, which preferably includes a release (e.g., DCBD) instruction for each of the n+1 elements of Dataset_0.The compiler 500 then inserts a second load sequence 536 containing several LD ​​instructions to implement the next iteration of the LOAD instruction 514 by loading the n+1 elements of Dataset_1 from the system memories 108 into the registers and cache memory hierarchy of a processor core 202.

[0041] It should be noted that release commands, apart from being automatically generated by a compiler, as in Fig.As shown in Figure 5, alternatively or additionally, the code can be specifically coded by a human coder or by an automatic code generator. Furthermore, it should be noted that if a release instruction is erroneously inserted into object code 506 before the last reference to the target cache line of the release instruction (for example, if the compiler, when processing data element [1,0], inserts a DCBD instruction targeting data element [0,n] before an instruction that references data element [0,n]), the premature inclusion of a release instruction causes a processing error and does not necessarily reduce the performance of the instruction that subsequently references the data element by increasing access latency. The access latency is not necessarily increased because the release instruction does not force the release of the target cache line, but merely makes a release more likely.As a result, depending on address access patterns and hit rates, a target cache memory line of a release command can be retained in the cache memory for many cache memory accesses following execution of the release command, thus enabling a subsequent command to potentially access the target cache memory line without causing the latency devaluation associated with re-fetching the target cache memory line from system memory.

[0042] Reference is now made to Fig.Figure 7 illustrates a logical flow diagram of an exemplary procedure by which a processor core 202 executes a release instruction according to one embodiment. The process begins at block 700 and then proceeds to block 702, which illustrates the ISU 201 of a processor core 202, which retrieves the next instruction set for execution from the memory hierarchy. The ISU 201 decodes the instructions in the instruction set and determines, as shown in block 704, whether any of the instructions in the instruction set are a release instruction (e.g., DCBD). For instructions other than release instructions, the ISU 201 may perform conventional processing, as shown in block 706. The ISU 201 assigns the release command(s) to the command group of the LSU 205 (block 710), which executes each release command to calculate the target address of the target cache memory line of the release command (block 712).After a possible conversion of the target address (e.g., from an effective to a real address), which is calculated by LSU 205, processor core 202 sends a release request corresponding to the release instruction to its connected L2 cache memory 230 (block 714), regardless of whether the target address is found in the L1 cache memory 204. As noted above, the release request, which preferably specifies a load transaction type and the calculated target address, is preferably transferred to the L2 cache memory 230 via the load pipeline 325. One consequence of implementing the release request as a load request rather than a memory request is that the release request only affects the caching of the target cache memory row within the cache memory hierarchy of the respective processor core 202 that executes the corresponding release instruction.As a result, processing of the deallocation request is not delayed by making the deallocation request visible to all cache hierarchies throughout the data processing system 100 or by the presence of locking operations (e.g., SYNCs) used in a sparsely ordered memory system to synchronize memory-modifying operations across all cache hierarchies and system memory 108. Following block 714, the execution sequence illustrated in [block 714] ends. Fig. 7 Process shown at block 716.

[0043] It will now Fig.Reference is made to Figure 8, which presents an overview diagram of the logical flow of an exemplary procedure by which a lower-level cache memory processes a release request according to one embodiment. The illustrated process begins at block 800 and then proceeds to block 802, which illustrates a lower-level cache memory, such as an L2 cache 230, that receives a release request from the connected processor core 202, preferably via a load pipeline 325. As above, with reference to Fig. As noted in point 3, the release request is loaded into allocation pipeline 306, which accesses directory 308 using the target address specified in the release request.

[0044] If the target address does not find a match in directory 308 (i.e., a false positive), no further processing of the release request takes place in the lower-level cache. Accordingly, in one embodiment, the release request is simply dropped from allocation pipeline 306, and the process terminates at block 820. In an alternative embodiment, allocation pipeline 306 forwards the release request to the next-level cache (e.g., L3 cache 232) in the cache hierarchy, as shown in optional block 816. In embodiments that include block 816, the release request can be processed in the next-level cache in the same way as shown in the Fig.Figure 8 illustrates this. In at least some embodiments, a more sophisticated cache management is implemented by including a hierarchy level indicator in the release request, specifying how far down the cache hierarchy the release request must be passed. In this way, for example, a release request can specify that the release request should be processed in the L2 and L3 caches, but not in the L4 cache, which is located at an even lower level. Following block 816, the Fig. 8 process shown at block 820.

[0045] Returning to block 810, allocation pipeline 306, in response to the target address of the share request that achieves a match in directory 308, updates the replacement order recorded for the target cache row to demote the target cache row, thereby increasing the likelihood that the target cache row will be selected as the choice cache row to be purged from its congruence class on a subsequent mismatch of a memory access request that creates an association to that congruence class (block 812).For example, if L2 cache 230 implements an LRU or pseudo-LRU replacement strategy, allocation pipeline 306 can update the chronology field 418 of the replacement order field 416 of the directory entry 410 belonging to the target cache row to LRU (or another predefined chronology position that is more likely to be purged, such as LRU+1). If L2 cache 230 implements a different replacement strategy, allocation pipeline 306 updates the replacement order field 416 accordingly to increase the probability that the target cache row will be selected as the choice cache row to be purged from its congruence class.While updating the replacement order for the target cache row, allocation pipeline 306 preferentially does not modify the identifier field 412 or the status field 414 of the directory entry 410 associated with the target cache row, does not access the target cache row in data array 302, and does not allocate RC machine 231 to process the release request. Because the release request with respect to directory 308 is fully served in allocation pipeline 306, a sequence of release requests, such as a release sequence 534, can be used without any issues. Fig. 5 will be served with a maximum allocation rate of allocation pipeline 306.

[0046] As shown in optional block 814, by updating directory entry 410, which is associated with the target cache row of the release request, allocation pipeline 306 also sets the T (transition) field 420 in directory entry 410, which is associated with the target cache row. Setting the T field 420 allows the fact that the associated cache row was the target of an explicit release request from processor core 202 to be preserved while the target cache row traverses the cache hierarchy. Consequently, when the target cache row is eventually purged and sent to a lower-level cache (e.g., L3), the lower-level cache can immediately place the target cache rows at a selected position in the replacement order that increases the likelihood of the target cache row being purged (e.g.,LRU or LRU+1 instead of MRU).

[0047] In addition to block 812 and, if implemented, the optional block 814, the process performed in the event of a cache hit may optionally include sending the release request to one or more cache levels, as shown in block 816 and as described above. Fig. The process shown in Figure 8 then ends at block 820.

[0048] It will now Fig. Reference is made to Figure 9, which illustrates an overview diagram of a logical flow of an exemplary method by which a subordinate level cache memory processes a memory access request of an attached processor core 202 according to an embodiment. The diagram in Figure 9 illustrates the following: Fig.The process shown in Figure 9 begins at block 900 and proceeds to block 902, which illustrates a lower-level cache, such as an L2 cache 230, that receives a memory access request (e.g., a load request or a memory request) from an attached processor core 202. As described above, the request is processed in the allocation pipeline 306, which performs a search in directory 308 to access directory data for the target cache row, allocates an RC machine 231 to serve the memory access request, and passes the memory access request and the directory data for the target cache row to the allocated RC machine 231 for processing.

[0049] At block 904, RC machine 231 uses the directory data of the target cache row to determine whether the target address of the memory access request in directory 308 has a match in a coherence state that allows the memory access request to be served without issuing an operation in the connection structure. As can be seen, the child-level cache can generally fulfill a non-modifying request without issuing a connection operation if status field 414 indicates any "Data Valid" coherence state for the target cache row. The child-level cache cannot generally fulfill a memory-modifying request without issuing a connection operation unless status field 414 indicates a "Modified" or "Exclusive" (or similar) coherence state for the target cache row.

[0050] In response to a confirmatory statement in block 904, in some embodiments the process proceeds to block 910, which represents the RC machine 231. This machine performs the steps necessary to serve the memory access request without issuing an operation in the connection structure (e.g., issuing a directory write request and / or providing load data to the processor core 202 or writing memory data to the data array 302). In embodiments implementing the T-field 420, the RC machine 231 additionally determines at block 906 whether the directory data received from the allocation pipeline 306 indicates that the T-field 420 of the target cache memory row is set such that the target cache memory row is identified as the target of a previous release request from the connected processor core 202. Otherwise, the process proceeds to block 910, which has already been described.If, however, RC machine 231 detects at block 906 that the T-field 420 is set, RC machine 231 includes in a directory write request a request to set the substitution order field 416 of the target cache memory row of the memory access request according to a desired strategy (block 908). For example, in various embodiments, RC machine 231 can set the target memory block to a predefined substitution order position (e.g., LRU), increment the substitution order position by one (e.g., update the target memory block from LRU to LRU+1), or reset the T-field 420 and set the substitution order position to Most Recently Used (MRU).The strategy for processing a match in a cache memory row when a T-field 420 is specified is preferably selected from these embodiments such that it corresponds to the expected data access patterns of the current workload. The process transitions from block 908 to block 910, which has already been described. Following block 910, the process ends in... Fig. Figure 9 illustrated the process at Block 924.

[0051] Returning to block 904, the process proceeds to block 916 in response to RC machine 231 determining that the memory access request cannot be served without issuing a connection operation. Block 916 illustrates RC machine 231 issuing a suitable connection operation in the connection structure to allow the memory access request to be served. Generally, the connection operation includes at least a transaction type and a destination address. Following block 916, the process proceeds to block 918, which represents RC machine 231 issuing a combined response from coherence management logic 210 ( Fig. 2). As previously discussed, the combined response is generated by response logic 210 from partial responses from snoopers within data processing system 100 and represents a system-wide response to the memory access request.

[0052] The process proceeds to block 920, which represents RC machine 231, determining whether the combined response of the connection operation indicates "success" or "retry." If the combined response indicates "retry" (that the request cannot be fulfilled at present and must be retried), the process returns to block 916, which has already been described. If the combined response indicates "success" (that the request can be fulfilled at present), the process returns to block 922, which illustrates RC machine 231 performing operations to serve the memory access request as indicated by the combined response.For example, if the connection operation request was a read operation, RC machine 231 causes the requested data received from the connection structure to be provided to processor core 202, the read data to be installed in data array 302, and an update to directory 308 to be performed. Conversely, if the connection operation was a store operation, RC machine 231 causes the cache memory array 302 to be updated with the storage data provided by the requesting processing unit 202, and also causes directory 308 to be updated.

[0053] If the target cache memory row was not in data array 302 prior to the connection operation, RC machine 231 will in any case cause a CO machine 310 to be allocated to clear a selection cache memory row and associated directory data from the congruence class to which the target address of the memory access request is assigned. If the lower-level cache memory is an L2 cache memory 230, the CO machine 310 preferentially writes the selection cache memory line to one of the L3 cache memories 232 via a castout operation. In embodiments where the T fields 420 are implemented within the directory entries 410, the directory data transferred to the L3 cache memory 232 during the castout operation includes setting the T field 420 (i.e., indicating whether the cache memory line was the target of a previous release request from the attached processor core 202).Following block 922, the [section] ends in [location]. Fig. 9. Exemplary process shown at Block 924.

[0054] It will now Fig. Reference is made to Figure 10, which presents an overview diagram of the logical flow of an exemplary process by which a subordinate level cache, hereinafter assumed to be an L3 cache 232, processes a castout operation of a superior level cache, hereinafter assumed to be an L2 cache 230, according to one embodiment. The process begins at block 1000 of Fig.10 and then proceeds to block 1002, where the process iterates until the L3 cache 232 receives a cast-in request 264 from the associated L2 cache 230. In response to receiving a cast-in request 264, the L3 cache 232 writes the directory data and any data received in the cast-in request 264 to the directory and data array of the L3 cache 232 (block 1004). Depending on the coherence protocol implemented in the data processing system 100, the cast-out cache row may have a different coherence state in the L3 cache 232 than the cast-out cache row had when it was purged from the L2 cache 230.

[0055] In embodiments where T-field 420 is not implemented, the L3 cache 232 sets the replacement order field 416 in the L3 cache directory for the cache row to MRU, as shown in block 1008. In alternative embodiments where T-field 420 is implemented, the L3 cache 232 also checks whether T-field 420, which is associated with the cache row undergoing castout, is set in the directory data provided in the cast-in request 264 (block 1006). Otherwise, the process proceeds to block 1008, as previously described.If, however, the L3 cache 232 determines in block 1006 that the T-field 420, which belongs to the cache row undergoing castout, is set, the L3 cache 232 sets the replacement order field 416 for the cache row to a specific replacement order position, thereby increasing the probability that the cache row will be purged from the L3 cache 232 in response to a subsequent cast-in request 264 (e.g., LRU or LRU+1), as shown in block 1010. The cast-in process ends either after block 1008 or after block 1010. Fig. 10. Process shown at block 1012.

[0056] In at least one embodiment, a data processing system includes a processor core supported by higher-level and lower-level cache memory. In response to the execution of a release instruction in the processor core, a release request is sent from the processor core to the lower-level cache memory, the release request specifying a destination address corresponding to a target cache memory row. Upon receiving the release request in the lower-level cache memory, it is determined whether the destination address is found in the lower-level cache memory.In response to a determination that the target address has a match in the child level cache, the target cache row is retained in a data array of the child level cache, and a replacement order field in a directory of the child level cache is updated to increase the likelihood that the target cache row will be purged from the child level cache in response to a subsequent cache mismatch.

[0057] In at least one embodiment, in response to a subsequent cache mismatch in the congruence class containing the target cache row, the lower-level cache performs a castout operation on the target cache row, marking it as having been the target of a previous processor core release request. This castout then writes the target cache row to a cache of a further lower level. In response to this marking, the replacement order field in a directory of the cache of the further lower level is updated, increasing the likelihood that the target cache row will be cleared from the cache of the further lower level.

[0058] Although, for example, aspects of the present invention have been described with regard to the hardware of a data processing system, it is understood that one or more embodiments of the present invention can alternatively be implemented as a program product for use with a data processing system. Such a program product includes a physical, computer-readable storage unit / medium that stores program code controlling the functions of the present invention. The computer-readable storage unit / medium can be implemented, for example, as a CD-ROM, DVD, floppy disk or hard disk, system memory, flash memory, etc.

Claims

[1] A method for processing data in a data processing system (100) including a processor core (202) supported by higher-level and lower-level cache memories (204; 230; 232), the method comprising: automatic insertion of a release instruction by a compiler (500) into a program code executed by the processor core (202), wherein the automatic insertion includes the compiler (500) automatically inserting the release instruction into the program code in response to detecting an end of processing of a data set, Executing the release command by the processor core (202) upon completion of processing a data set including a target cache line and a plurality of other cache lines to assist in flushing the data set from the lower-level cache (230; 232), in response to executing the release command in the processor core (202), sending a release request from the processor core (202) to the lower-level cache (230; 232), the release request specifying a target address associated with the target cache line; in response to receiving the release request in the lower-level cache (230; 232), determining whether the target address hits the lower-level cache (230; 232); and in response to determining that the target address hits the lower-level cache (230; 232), maintaining the target cache line in a data array (302) of the lower-level cache (230; 232) and updating a replacement order field (416) in a directory (308) of the lower-level cache (230; 232) such that the target cache line is more likely to be evicted from the lower-level cache (230; 232) in response to a subsequent cache miss in a congruence class that includes the target cache line. [2] The method of claim 1, wherein updating the replacement order field (416) includes making the target cache line the least recently used (LRU). [3] The method of claim 1, and further comprising: then releasing the target cache line from the lower-level cache (230; 232) in response to a data access request missing in the lower-level cache (230; 232). [4] The method of claim 1, and further comprising: thereafter, in response to accessing the target cache line in the lower-level cache (230; 232) prior to flushing the target cache line from the lower-level cache (230; 232), refraining from updating the replacement order field (416). [5] The method of claim 1, wherein: the cache memory (230; 232) of the subordinate level has a loading and a memory pipeline (325) for data access requests of the processor core (202); and sending the release request includes sending the release request to the load pipeline (325) of the lower-level cache (230; 232). [6] The method of claim 1, wherein: the lower-level cache (230; 232) includes the contents of the higher-level cache (204; 230); and sending comprises sending the release request to the lower-level cache (230; 232) regardless of whether the target address hits the higher-level cache (204; 230). [7] The method of claim 1, wherein: the lower-level cache memory (230; 232) includes a plurality of state machines (231) that service data access requests of the processor (202); and the retaining and updating is performed without associating one of the plurality of state machines with the release request. [8] The method of claim 1, and further comprising: in response to determining that the target address hits in the lower-level cache (230; 232), maintaining a previous coherency state associated with the target cache line in the cache directory (308).

Images