A distributed hot cache line fairness tracking mechanism

Abstract

An embodiment is for using a distributed hot cache line fairness tracking mechanism, in response to receiving an incoming request to access a cache line, making a decision to grant access to the cache line based on a request state and a service state used to maintain the cache line, the structure including the request state and the service state, in response to the decision to grant access to the cache line, the request state and the service state are forwarded along with data for the cache line.

Description

[Technical field]

[0001] The present invention relates generally to computer systems, and more particularly to computer-implemented methods, computer systems, and computer program products constructed and arranged to use a distributed hot cache line fairness tracking mechanism. [Background technology]

[0002] In a computing environment with multiple processor chips in the same drawer and / or processor chips in other drawers that share one or more caches, such processor chips may have access to the same cache line. A cache line or line is a portion of data of a particular size (e.g., 256 bytes) that fits into a single cache entry in a cache. When data is transferred between memory and the cache, consistency is managed at the granularity of a cache line. To ensure cache line consistency, snoop requests (also called snoop or fetch requests) are used. A snoop request is handled by receiving a snoop request from the requesting cache, determining whether this cache has a copy of the cache line in the appropriate state, sending the cache line to the requesting cache, and updating the state of the cache line in this cache.

[0003] Cache structures and related services provide data coherency for shared data among processor chips. Many processor chips in the same drawer, or processor chips in different drawers, or both, may attempt to access the same cache line. Techniques are needed to improve access to cache lines in a shared cache. Summary of the Invention

[0004] According to a first aspect, a computer-implemented method is provided that includes, in response to receiving an incoming request to access a cache line, making a decision to grant access to the cache line based on a request state and a service state associated with the cache line, the structure including the request state and the service state; and, in response to the decision to grant access to the cache line, transferring the request state and the service state along with data for the cache line.

[0005] According to another aspect, there is provided a computer program comprising program code means adapted to perform the method of the preceding paragraph when the program is run on a computer.

[0006] According to another aspect, a system is provided that includes a shared cache and a controller coupled to the shared cache, wherein the controller, in response to receiving an incoming request to access a cache line, makes a decision to grant access to the cache line based on a request state and a service state associated with the cache line, the structure including the request state and the service state, and is configured to forward the request state and the service state along with data for the cache line in response to the decision to grant access to the cache line.

[0007] According to another aspect, a controller is provided having logic executable to perform operations including, in response to receiving an incoming request to access a cache line, making a decision to grant access to the cache line based on a request state and a service state associated with the cache line, the structure making the granting decision including the request state and the service state; and, in response to the decision to grant access to the cache line, transferring the request state and the service state along with data of the cache line.

[0008] According to another aspect, a computer-implemented method is provided that includes: in response to receiving an incoming request to access the cache line from a requester, making a decision to deny access to the cache line based on a request state and a service state associated with the cache line, the structure including the request state and the service state; in response to the decision to deny access to the cache line, setting a bit in the request state, the bit corresponding to the requester; and in response to receiving another incoming request to access the cache line from the requester, making another decision to grant access to the cache line for the other incoming request based on the bit set in the request state and the service state; and forwarding the request state and service state to the requester along with data for the cache line.

[0009] According to another aspect, there is provided a computer program comprising program code means adapted to perform the method of the preceding paragraph when the program is run on a computer.

[0010] According to another aspect, a system is provided that includes a shared cache and a controller coupled to the shared cache, wherein the controller is configured, in response to receiving an incoming request to access the cache line from a requester, to make a decision to deny access to the cache line based on a request state and a service state associated with the cache line, the structure including the request state and the service state, in response to the decision to deny access to the cache line, to set a bit in the request state, the bit corresponding to the requester, and in response to receiving another incoming request to access the cache line from the requester, to make another decision to grant access to the cache line for the other incoming request based on the bit set in the request state and the service state, and to forward the request state and service state to the requester along with data for the cache line.

[0011] An embodiment of the present invention relates to a computer-implemented method for using a distributed hot cache line fairness tracking mechanism. The non-limiting computer-implemented method includes, in response to receiving an incoming request to access a cache line, making a decision to grant access to the cache line based on a request state and a service state associated with the cache line. In response to the decision to grant access to the cache line, the method includes forwarding the request state and the service state along with data for the cache line.

[0012] This may provide an improvement over known methods of handling cache requests by efficiently providing a fairness tracking mechanism to ensure that all requesters requiring access to a cache line receive timely and fair access to the line. One or more embodiments of the present invention overcome the scalability problems of conventional implementations by using a distributed, hierarchical hot cache line fairness mechanism.

[0013] In addition to or as an alternative to one or more of the features described above or below, in further embodiments of the invention, the request state and the service state are forwarded to the controller making the incoming request. One or more embodiments use two vectors that are allocated, deallocated, and associated with each cache line, and these vectors are communicated to the system along with the data of each cache line, advantageously eliminating the need for large centralized physical space in the design. These vectors are additionally structured hierarchically, reducing the storage space required.

[0014] In addition to or as an alternative to one or more of the features described above or below, in further embodiments of the invention, the request state and the service state are forwarded from the controller that received the incoming request. In one or more embodiments, two vectors are used per cache line, which are advantageously conveyed to the system along with the data for each cache line, eliminating the need for large centralized physical space in the design. These vectors are additionally structured hierarchically, reducing the storage space required.

[0015] In addition to or as an alternative to one or more features described above or below, in further embodiments of the invention, the request state is configured to track requests to access cache lines that have been observed but not granted. In one or more embodiments, two vectors are provided that work together to form an encoded state of where hot cache lines have been requested and where cache lines have already been granted access, which advantageously eliminates the need for large centralized physical space in the design. If a requester re-requests the same cache line (having already been granted access to the hot cache line once before), it cannot receive the cache line again if there are other requesters that have previously requested the cache line but have not yet been granted access.

[0016] In addition to or as an alternative to one or more of the features described above or below, in further embodiments of the invention, the service state is configured to track requests to access cache lines that have been observed and that have been granted access to the cache lines. In one or more embodiments, two vectors are provided that work together to form an encoded state of where hot cache lines have been requested and where hot cache lines have already been granted access, which advantageously eliminates the need for large centralized physical space in the design. If a requester re-requests the same cache line (having already been granted access to the hot cache line once before), it cannot receive the line again if there are other requesters that have previously requested the cache line but have not yet been granted access.

[0017] In addition to or as an alternative to one or more of the features described above or below, in further embodiments of the present invention, the request state and the service state are configured to be forwarded to multiple controllers in the computing environment. One or more embodiments of the present invention overcome the scalability problems of conventional implementations by using a distributed, hierarchical hot cache line fairness mechanism.

[0018] An embodiment of the present invention relates to a method of using a distributed hot cache line fairness tracking mechanism. A non-limiting computer-implemented method includes, in response to receiving an incoming request to access a cache line from a requester, making a decision to deny access to the cache line based on a request state and a service state associated with the cache line, where the structure includes the request state and the service state. In response to the decision to deny access to the cache line, the method includes setting a bit in the request state, where the bit corresponds to the requester. In response to receiving another incoming request to access the cache line from the requester, making another decision to grant access to the cache line to another incoming request based on the bit set in the request state and the service state, and forwarding the request state and the service state along with data for the cache line to the requester.

[0019] This may provide an improvement over known methods of handling cache requests by efficiently providing a fairness tracking mechanism that ensures that all requestors requiring access to a cache line receive timely and fair access to the cache line. One or more embodiments of the present invention overcome the scalability problems of conventional implementations by using a distributed, hierarchical hot cache line fairness mechanism.

[0020] Other embodiments of the present invention embody features of the methods described above in computer systems and computer program products.

[0021] Further technical features and advantages are realized by the techniques of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, reference is made to the detailed description and drawings.

[0022] The particulars of the exclusive rights set forth herein are particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing, as well as other features and advantages of embodiments of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings. [Brief description of the drawings]

[0023] [Figure 1] FIG. 1 is a block diagram of an exemplary computer system for use with one or more embodiments of the present invention. [Diagram 2] FIG. 1 is a block diagram of an example system configured to provide a distributed hot cache line fairness tracking mechanism in accordance with one or more embodiments of the present invention. [Diagram 3] 1 is a block diagram of an exemplary shared cache configured to provide a distributed hot cache line fairness tracking mechanism in accordance with one or more embodiments of the present invention. [Figure 4] FIG. 1 is a block diagram illustrating an exemplary requested vector and an exemplary serviced vector per cache line in distributed, hierarchical, hot-line fairness tracking in accordance with one or more embodiments of the present invention. [Figure 5A] FIG. 2 illustrates an exemplary chip scope of a hardware controller in accordance with one or more embodiments of the present invention. [Figure 5B] FIG. 2 illustrates an example drawer scope of a hardware controller in accordance with one or more embodiments of the present invention. [Figure 5C] FIG. 2 illustrates an exemplary system scope of a hardware controller in accordance with one or more embodiments of the present invention. [Figure 6] FIG. 1 is a block diagram illustrating an example of maintaining and passing vectors to track fairness of distributed hot cache lines in accordance with one or more embodiments of the present invention. [Figure 7A]FIG. 1 is a block diagram illustrating an example of maintaining and passing vectors to track fairness of distributed hot cache lines in accordance with one or more embodiments of the present invention. [Figure 7B] FIG. 1 is a block diagram illustrating an example of maintaining and passing vectors to track fairness of distributed hot cache lines in accordance with one or more embodiments of the present invention. [Figure 8] 1 is a flowchart of a computer-implemented process of a distributed hot cache line fairness tracking mechanism for accessing cache lines of a shared cache in accordance with one or more embodiments of the present invention. [Figure 9] 1 is a flowchart of a computer-implemented method for performing a distributed hot cache line fairness tracking mechanism for cache lines of a shared cache in accordance with one or more embodiments of the present invention. [Figure 10] 1 is a flowchart of a computer-implemented method for performing a distributed hot cache line fairness tracking mechanism for cache lines of a shared cache in accordance with one or more embodiments of the present invention. [Figure 11] FIG. 1 illustrates a cloud computing environment in accordance with one or more embodiments of the present invention. [Figure 12] FIG. 2 illustrates an abstraction model layer in accordance with one or more embodiments of the present invention. [Figure 13] 1 is a block diagram of a system for designing / layouting an integrated circuit (IC) that uses a distributed hot cache line fairness mechanism within the IC in accordance with one or more embodiments of the present invention. [Figure 14] 14 illustrates a process flow for a method of manufacturing the IC of FIG. 13 in accordance with one or more embodiments of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] One or more embodiments of the present invention are configured to provide a distributed hot cache line fairness tracking mechanism. One or more embodiments of the present invention provide a technique for distributed tracking of hot line (cache line) requests using two vectors that are allocated, deallocated, and associated with each cache line. One vector is a request vector, and the other vector is a service vector. The request vector is a vector that tracks requests to access cache lines where the request has been observed but access has not been granted. The service vector is a vector that tracks requests to access cache lines where the request has been observed and access to the cache line has been granted. The request vector and the service vector travel through the system on a cache line by cache line basis along with each cache line's data, eliminating the need for large centralized physical space in the design. The request vector and the service vector are additionally structured in a hierarchical manner, reducing the storage space required. The two vectors, the request vector and the service vector, work together to form an encoded state that indicates where the hot cache line has been requested and where (e.g., by whom) the hot cache line has already been granted access. A requester that re-requests the same cache line (i.e., has already been granted access to the hot cache line once before) cannot receive the cache line again if there are other requesters that have previously requested the cache line but have not yet been granted access.

[0025] A hot line, or hot cache line, is a cache line that has many operations accessing it as a requester, attempting to observe and / or modify it. A cache line can only be accessed by one operation at a time. If there are multiple requests to access a cache line, a backlog of operations waiting to access the cache line occurs because another operation is working on that cache line. Unsuccessful requesters that request the cache line but cannot access it are turned away and must start the request process over again. Meanwhile, requesters that have already accessed the cache line can request the line again, and their requests may arrive before the unsuccessful requester returns to ask for (i.e., claim) the cache line. This can cause the unsuccessful requester to become starved, or locked out, as other requesters keep accessing the cache line repeatedly, causing the unsuccessful requester to wait a long time to obtain the cache line. This type of behavior can adversely affect performance and response times, as the operation that requested the cache line will be stuck there for a long time, making no progress.

[0026] Thus, one or more embodiments of the present invention provide a fairness tracking mechanism to ensure that all requesters requiring access to a cache line receive timely and fair access to the cache line. As technical solutions and advantages, one or more embodiments improve performance and response time of cache requests from requesters by using request vectors and service vectors to ensure progress is made.

[0027] For the sake of brevity, the present specification may or may not describe in detail conventional techniques relating to semiconductor device and IC manufacturing methods. Moreover, various tasks and process steps described herein may be incorporated into more comprehensive procedures or processes having additional steps or functions not described in detail herein. In particular, the various steps in the manufacture of semiconductor devices and semiconductor-based ICs are well known, and therefore, for the sake of brevity, many conventional steps are only briefly mentioned herein or are omitted entirely without presenting details of the well-known processes.

[0028] Turning now to FIG. 1, a computer system 100 is generally illustrated in accordance with one or more embodiments of the present invention. Computer system 100 may be an electronic computer framework that includes and / or uses any number and combination of computing devices and networks utilizing various communication technologies as described herein. Computer system 100 may be easily scalable, extensible, and modular, and may have the ability to be modified into different services or reconfigured for some functions independently of other functions. Computer system 100 may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. Computer system 100 may be a cloud computing node in some examples. Computer system 100 may be described in the general category of computer system executable instructions, such as program modules, executed by the computer system. Program modules may generally include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system 100 may operate in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0029] Computer system 100 includes one or more central processing units (CPUs) 101a, 101b, 101c, etc. (collectively or generically referred to as processors 101), as shown in FIG. 1. Processor 101 may be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. Processor 101, also referred to as a processing circuit, is coupled to system memory 103 and various other components via a system bus 102. System memory 103 may include read only memory (ROM) 104 and random access memory (RAM) 105. ROM 104 may include a basic input / output system (BIOS) or its successor, such as a Unified Extensible Firmware Interface (UEFI), coupled to system bus 102 and controlling certain basic functions of computer system 100. RAM is a read / write memory coupled to system bus 102 for use by processor 101. System memory 103 provides temporary memory space for manipulating instructions during operation. System memory 103 may include random access memory (RAM), read only memory, flash memory, or other suitable memory system.

[0030] Computer system 100 includes an input / output (I / O) adapter 106 and a communications adapter 107 coupled to a system bus 102. I / O adapter 106 may be a small computer system interface (SCSI) adapter that communicates with a hard disk 108 and / or other similar components. I / O adapter 106 and hard disk 108 are collectively referred to herein as mass storage 110.

[0031] The software 111 executed by the computer system 100 may be stored in the mass storage 110. The mass storage 110 is an example of a tangible storage medium readable by the processor 101, in which the software 111 is stored as instructions for the processor 101 to execute and operate the computer system 100, as described below in connection with the various figures herein. Examples of computer program products and the execution of such instructions are discussed in more detail herein. The communications adapter 107 interconnects the system bus 102 with a network 112, which may be an external network, enabling the computer system 100 to communicate with other such systems. In one embodiment, a portion of the system memory 103 and the mass storage 110 collectively store an operating system, which may be any suitable operating system that coordinates the functions of the various components illustrated in FIG. 1.

[0032] Additional input / output devices are shown connected to the system bus 102 via a display adapter 115 and an interface adapter 116. Adapters 106, 107, 115, and 116 may be connected to one or more I / O buses, which in one embodiment are connected to the system bus 102 via an intermediate bus bridge (not shown). A display 119 (e.g., a screen or display monitor) is connected to the system bus 102 through the display adapter 115 and may include a graphics controller and a video controller to improve performance of graphics-intensive applications. A keyboard 121, a mouse 122, speakers 123, etc. may be interconnected to the system bus 102 via the interface adapter 116, which may include, for example, a super I / O chip that combines multiple device adapters into a single integrated circuit. I / O buses suitable for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe). Thus, computer system 100, as configured in FIG. 1, includes processing functionality in the form of processor 101, storage functionality including system memory 103 and mass storage 110, input means such as keyboard 121 and mouse 122, and output functionality including speaker 123 and display 119.

[0033] The communications adapter 107 may transmit data using any suitable interface or protocol, such as an Internet Small Computer System Interface, among others, in some embodiments. The network 112 may be a mobile communications network, a wireless network, a wide area network (WAN), a local area network (LAN), or the Internet, among others. External computing devices may be connected to the computer system 100 through the network 112. The external computing devices may be external web servers or cloud computing nodes, in some examples.

[0034] It should be understood that the block diagram of Figure 1 is not intended to indicate that computer system 100 includes all of the components depicted in Figure 1. Rather, computer system 100 may include suitable fewer or additional components (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.) not depicted in Figure 1. Additionally, the embodiments described herein with respect to computer system 100 may be implemented using any suitable logic, and logic referred to herein may include, in various embodiments, any suitable hardware (e.g., a processor, an embedded controller, or an application specific integrated circuit, among others), software (e.g., an application, among others), firmware, or any suitable combination of hardware, software, and firmware.

[0035] FIG. 2 illustrates a block diagram of an exemplary system 200 configured to provide a distributed hot cache line fairness tracking mechanism in accordance with one or more embodiments of the present invention. System 200 may include a number of interconnected drawers 202, such as Drawer 0, Drawer 1, and Drawer 2. Each of drawers 202 includes a processor chip 204, such as Processor Chip 0, Processor Chip 1, and Processor Chip 2. Each processor chip 204 is coupled to and / or includes a shared cache 206 (e.g., a Level 3 (L3) cache), such as L30, L31, L32, and L33. FIG. 3 illustrates further details of an exemplary shared cache 206. Computer system 100 may be integrated with and / or use processor chip 204 of FIG. 2. Many computer systems 100 and / or functions of computer systems 100 may be integrated into system 200. System 200 may represent one or more portions of cloud computing environment 50 shown in Figure 11. One or more processors 101 may represent a processor chip 204. Processor chip 204 includes all standard processing circuitry, and shared cache 206 includes standard memory and circuitry as would be understood by one of ordinary skill in the art. The processor chip may include higher level caches, such as an L2 cache and an L1 cache, not shown for simplicity, with the L1 cache being closest to the processor core, as would be understood by one of ordinary skill in the art.

[0036] FIG. 3 illustrates a block diagram of an example shared cache 206 (e.g., L30, L31, L32, L33) configured to provide a distributed hot cache line fairness tracking mechanism in accordance with one or more embodiments of the present invention. Although FIG. 3 illustrates details of a single shared cache 206, the discussion applies to the other shared caches 206 as well. The shared cache 206 may include and / or be coupled with various hardware controllers 350 that, in accordance with one or more embodiments, are configured to control accesses, such as reads or writes, to cache lines of the shared cache 206, send requests to access other cache lines of other shared caches 206, and implement request and service vectors for each cache line. Each hardware controller 350 includes logic 320 configured to, among other things, enable distributed hot cache line fairness tracking using the request and service vectors. A hardware controller 350 may have in memory 322 the request and service vectors for a single cache line, which are communicated as metadata along with the data in the cache line to the next hardware controller 350. Thus, each cache line in the shared cache 206 has its own request and service vectors, which are maintained and passed throughout the system 200 according to one or more embodiments.

[0037] Hardware controller 350 may comprise the functionality of one or more known hardware controllers. Hardware controller 350 may be and / or have the functionality of a local fetch address register controller (LFAR), a control store address register controller (CSAR), a central processor fetch controller (CFAR), a remote fetch controller (RFAR), a line local store address register controller (L-LSAR), a remote local store address register controller (R-LSAR), a remote store address controller (RSAR), and other hardware controllers as understood by those skilled in the art. Logic 320 may comprise logic circuitry, firmware executable on the circuitry of hardware controller 350, or a combination of logic circuitry and firmware, or a combination of both. Logic 320 may also be embodied as instructions stored on a computer-readable storage medium, a hardware module, special purpose hardware (e.g., application specific hardware, application specific integrated circuits (ASICs), embedded controllers, hardwired circuitry, etc.), or some combination or combinations thereof. Logic 320 as described herein may be a combination of hardware and programming, in examples.The programming may be processor executable instructions stored in a tangible memory, and the hardware may comprise processing circuitry to execute such instructions. The logic 320 may alternatively or additionally include dedicated hardware, such as one or more integrated circuits, application specific integrated circuits (ASICs), application specific special processors (ASSPs), field programmable gate arrays (FPGAs), or any combination of the aforementioned dedicated hardware examples, for performing the techniques described herein. The logic 320 of the shared cache hardware controller 350 is configured to provide a distributed, hierarchical, hot-line fairness tracking mechanism that is comparable in performance to centralized fairness tracking and is scalable. The distributed mechanism grows organically and does not require additional space per address. The distributed, hierarchical fairness tracking mechanism uses request vectors and service vectors that are allocated, deallocated, and associated with a single cache line, as referred to herein.

[0038] FIG. 4 illustrates a block diagram showing exemplary request vectors and exemplary service vectors used per cache line in distributed, hierarchical hot line fairness tracking, according to one or more embodiments. The request vectors and service vectors travel through the system 200 simultaneously as the cache line's data is passed, eliminating the need for a large centralized physical space in the design. Each cache line has its own request vector and service vector. The request vectors and service vectors are additionally structured hierarchically, reducing the storage space required compared to a centralized queue. The service vector is a vector that tracks requests to access cache lines that have been observed and granted access to the cache line. The request vector is a vector that tracks requests to access cache lines that have been observed but not granted access. The request vectors and service vectors work together to form an encoded state of where hot cache lines have been requested and where hot cache lines have already been granted access. A requester that re-requests the same cache line (and has already been granted access to the hot cache line once before) will not be able to receive the line again if there are other requesters that also want the cache line but have not yet been granted access.

[0039] As shown in FIG. 4, which provides further details of the structure of the service and request vectors, each vector has a scope that can be defined to function as needed. FIG. 4 illustrates an example in which, in one or more embodiments, the service and request vectors each have three hierarchical scopes: chip scope, drawer scope, and system scope. In the hierarchy, the drawer scope is higher than the chip scope, and the system scope is higher than the drawer scope. Each vector is maintained in the hardware controller 350 rather than the directory 344, which minimizes the number of bits required since there are fewer hardware controllers 350 compared to the number of cache entries in the directory 344. Although the request and service vectors are described as vectors, it should be understood that each has a state for each requester, and any structure for maintaining, storing, and ultimately passing / forwarding each state can be utilized.

[0040] In FIG. 4, the lowest scope, chip scope, tracks requests from other shared caches 206 (e.g., other L3 caches) on the same chip as the current shared cache 206 that has access to the cache line. Each shared cache 206 (e.g., L3 cache) on a chip 204 has a unique bit in the service vector and request vector that corresponds to the particular shared cache 206. FIG. 5A illustrates an example chip scope of an example hardware controller 350 according to one or more embodiments. The chip scope of the vectors can represent the request vector or the service vector, or both, in FIG. 5A. Since each processor chip (e.g., chip 0, chip 1, chip 2) has four shared caches (L30, L31, L32, L33), there are four bit positions, one unique bit position assigned to each shared cache 206 on the processor chip (e.g., chip 0), as shown in FIG. 5A. Note that in this example, the bit position designations are from left to right, but the designations may be from right to left or some other designation. From left to right, the bit positions / locations in the chip scope correspond to L30, L31, L32, and L33 of the individual chips 204. Although four bits are shown to represent the four exemplary shared caches 206 in FIG. 2, more or fewer chip-scoped bits may be utilized depending on the number of shared caches 206 in the individual chips 204.

[0041] In FIG. 4, the drawer scope tracks requests from other chips 204 in the same drawer 202 as the controlling hardware controller 350 of the current shared cache 206 that has access to the cache line. Each chip 204 in the drawer 202 has a unique bit in the service vector and the request vector that corresponds to the particular chip 204. FIG. 5B illustrates an example drawer scope of an example hardware controller 350 according to one or more embodiments. The drawer scope of the vectors can represent the request vector or the service vector, or both, in FIG. 5B. Because each drawer 202 (e.g., Drawer 0, Drawer 1, Drawer 2) includes three processor chips 204 (e.g., Chip 0, Chip 1, Chip 2), there are three bit positions, one unique bit position assigned to each processor chip (e.g., Chip 0, Chip 1, Chip 2) of the drawer 202 (e.g., Drawer 0), as shown in FIG. 5B. From left to right, the bit positions / locations within the drawer scope correspond to chip 0, chip 1, and chip 2 of the individual drawers 202. Although three bits are shown to represent the three example chips 204 in FIG. 2, more or fewer drawer scope bits may be utilized depending on the number of chips 204 in the individual drawers 202.

[0042] In FIG. 4, the system scope tracks requests from other drawers 202. Each drawer 202 in the system 200 has a unique bit in the service vector and the request vector that corresponds to the particular drawer 202. FIG. 5C illustrates an example system scope of an example hardware controller 350, according to one or more embodiments. The system scope of the vectors can represent the request vector or the service vector, or both, in FIG. 5C. Because the system 200 has three drawers 202 (e.g., Drawer 0, Drawer 1, Drawer 2), there are three bit positions, one unique bit position assigned to each drawer 202 (e.g., Drawer 0, Drawer 1, Drawer 2) in the system 200, as shown in FIG. 5C. The bit positions / positions in the system scope correspond, from left to right, to Drawer 0, Drawer 1, and Drawer 2 in the system 200. Although three bits are shown to represent the three example drawers 202 in FIG. 2, more or fewer system-scoped bits may be utilized depending on the number of drawers 202 in the system 200.

[0043] The hardware controller 350 uses the authority level of a cache line to set and reset the bits it tracks in the request and service vectors of that cache line. Each cache line has its own associated request and service vectors. There are three types of authority levels, discussed below: global / system coherency authority, drawer coherency authority, and chip coherency authority. The global / system coherency authority (Global Intervention Master, or GIM) of a cache line is the highest point of coherency for that cache line if a copy of the GIM for the cache line is present in the shared cache 206. The hardware controller 350 obtains this authority for the cache line and its GIM authority from a previous GIM (authority) for that cache line, or by determining that no other copy of the GIM for the requested cache line exists in the system 200, in which case only that GIM has authority to receive the cache line from memory, or both. If an exclusive copy of a cache line exists in the shared cache, then that cache line must also be the GIM. The GIM of a cache line is also the Drawer Intervention Master, or DIM, for the cache line's drawer and the Chip Intervention Master, or CIM, for the cache line's chip. In a three-level hierarchy of intervention masters, only the GIM can return data in response to requests from other drawers, according to one or more embodiments. There can be only one GIM for a particular cache line in system 200.

[0044] Turning now to the drawer coherency authority (drawer intervention master, or DIM) of a cache line, the DIM is the highest level of authority for that cache line in a drawer 202. Hardware controller 350 obtains this authority by either receiving the DIM authority for a cache line from a previous DIM in that drawer 202 and / or by determining that no other copy of the requested cache line with a DIM exists in the drawer 202 and that only the DIM has authority to request the cache line from other drawers 202. When the shared copy and GIM authority of the cache line are passed to another drawer 202, the GIM copy of the cache line may be demoted to the DIM. If a shared cache 206 controlled by hardware controller 350 has a copy of the cache line with the DIM authority but not the GIM authority, hardware controller 350 must have a read-only copy of the line. The DIM for a cache line is also the CIM for the chip 204 for that cache line. In a three-level intervention master hierarchy, according to one or more embodiments, only the DIM can return data in response to requests from other chips in a drawer of a shared cache. There may be as many DIMs for a particular cache line in the system 200 as there are drawers 202, but only one per drawer.

[0045] The chip coherency authority (chip intervention master, or CIM) of a cache line is the highest level of authority for that cache line in a chip. The hardware controller 350 obtains this authority by receiving the CIM authority for the cache line from the chip's previous CIM for that cache line and / or by determining that no other copy with a CIM for the requested cache line exists on the chip, in which case only that CIM has authority to request the cache line from other chips. When the shared copy and DIM authority of the cache line are passed to another chip 204, the DIM copy of the line may be downgraded to a CIM. If a cache has a copy of the cache line with CIM authority but not GIM authority, the controlling hardware controller 350 must have a read-only copy of the line. In a three-level intervention master hierarchy, only the CIM can return data in response to requests from other shared caches in the chip's shared cache.

[0046] A non-intervention-master copy of a cache line is a read-only copy of the cache line in a shared cache 206 (e.g., an L3 cache) that does not have permission to share the cache line with other requesters. This may be considered the lowest level of coherency scope.

[0047] Turning to further details regarding maintaining the request and service vectors, an example of setting and resetting the bits tracked in the request and service vectors of a cache line will be discussed. The hardware controller 350 is responsible for setting and maintaining the fairness vector as referred to herein. Each hardware controller 350 updates both vectors (i.e., the request and service vectors) based not only on the on-chip and off-chip requests that the particular hardware controller 350 monitors, but also on the fairness that the hardware controller 350 receives when accessing a cache line. For example, when the hardware controller 350 receives data indicating that there are requesters that have not been serviced, the hardware controller 350 does not retire as it would normally after the hardware controller 350 returns the data to the processor core. Instead, the hardware controller 350 remains in an active state to protect the cache line until an eligible requester arrives. The hardware controller 350 ensures that requests (also called snoops) from ineligible requesters get a coherency reject while waiting for an eligible requester to arrive.

[0048] In order for the requestor to set the request-in-scope bit, the requestor must match with the local hardware controller 350 of the local shared cache, which has a privilege level to service both the requestor and the local shared cache 206 (e.g., an L3 cache). The local hardware controller is the controlling hardware controller of the cache line of a particular shared cache that serves that shared cache. A requestor requesting access to a cache line of a particular shared cache is the hardware controller of that shared cache of the requestor. Since each shared cache has its own hardware controller, the shared cache may sometimes be referred to as the requestor's cache line. The local hardware controller 350 of a local shared cache 206 (e.g., shared cache L30) must at least be established as the chip's coherency authority before the hardware controller 350 can begin tracking requests from other hardware controllers 350 corresponding to other shared caches 206 (e.g., other shared caches L31, L32, L33) of the processor chip 204 (e.g., processor chip 0) in order to set a bit in the chip-scoped request vector.

[0049] The local hardware controller 350 of the local shared cache 206 must be established as at least the drawer coherency authority before the hardware controller 350 can begin tracking requests from other chips 204 of the drawer 202 for cache lines of a particular shared cache in order to set a bit in the drawer-scoped request vector.

[0050] The local hardware controller 350 of a local shared cache 206 must be established as the system coherency authority before the hardware controller 350 can begin tracking requests from other drawers 202 in the system 200 for cache lines of a particular shared cache in order to set a bit in the system-scope request vector.

[0051] Such a configured limit is utilized because an observed request may otherwise be serviced by someone else (e.g., another hardware controller 350 of another shared cache 206 that actually has the appropriate permissions) and should not be counted as a request that should be serviced by the local hardware controller 350 of the shared cache 206.

[0052] The details of maintaining the request vector and the service vector are discussed below. In the service vector, the service bits of a scope (e.g., chip scope, drawer scope, and system scope) are set when the local hardware controller 350 of the corresponding shared cache 206 that has access to the data in the cache line sets the corresponding chip, drawer, and system bits of the local hardware controller 350 itself. In the request vector, the request bits of a scope (e.g., chip scope, drawer scope, and system scope) are reset when the corresponding service bits of the service vector are set in the same scope, as well as when the local shared cache 206 invalidates its own copy via the local shared cache 206 hardware controller 350, or when a timeout limit is reached, or both. In the service vector, the service bits of the scope (e.g., chip scope, drawer scope, and system scope) are reset when all known requesters have been serviced, when the local shared cache 206 invalidates its copy via the local shared cache 206 hardware controller 350, or when a timeout limit is reached, or a combination of these. The request and service bits of the lower scope are reset when the cache line is passed to a requester of a higher scope (i.e., if the cache line is passed to another drawer, the drawer vector is cleared, but if the cache line is passed to another chip in the same drawer, the drawer vector will retain the data of the drawer vector). Additionally, the drawer scope / vector refers to the chip of this drawer relative to the L3 cache that maintains the vector. If the cache line moves to another chip in the same drawer, the drawer vector value is still meaningful to the receiving chip since the drawer vectors of both the sending chip and the receiving chip refer to the same drawer chip.On the other hand, if a cache line moves to a different drawer's chip, the new drawer scope / vector created on the receiving chip will reference the receiving drawer, but the drawer scope / vector on the sending chip will reference the sending drawer's chip. The state of the drawer scope / vector from the sending drawer is meaningless to the receiving drawer, so the lower scope's request and service bits are reset when the cache line is handed off to the higher scope's requester.

[0053] The communication of the request vectors and service vectors to the system 200, thereby enabling a distributed hot cache line fairness tracking mechanism, will be discussed in more detail below. The request fairness vector and service fairness vector for each cache line are communicated as part of the metadata for that cache line (e.g., from one hardware controller 350 of a shared cache 206 to the next hardware controller 350 of a shared cache 206). Based on the result of checking the service bit in the service vector, only the requesters that have not been served can access the cache line next. All requesters that have been served are rejected and must come back to retry. The fairness vectors (i.e., the request vector and service vector) are not passed to the higher scope until no request bits in the request vector are set for the lower scope. The service bit / state in the service vector is eventually reset based on the rules already established.

[0054] 6 illustrates a block diagram showing an example of maintaining and passing vectors for distributed hot cache line fairness tracking, according to one or more embodiments of the present invention. This exemplary scenario updates and passes vectors on-chip, e.g., passing request vectors and service vectors on the same chip 0. Thus, the exemplary scenario illustrates chip scope and drawer scope, but not system scope, for ease of understanding. It should be understood that system scope applies by analogy.

[0055] In action 601, shared cache L30 (which is a shared cache 206) has access and / or control to a cache line of a particular shared cache 206 through a controlling hardware controller 350 of shared cache L30. Controlling hardware controller 350 is a designation used for purposes of explanation to indicate that a hardware controller has control of a cache line of a particular shared cache. In this example, there are four shared caches 206 (e.g., L30, L31, L32, L33) in the chip scope, indicated by four bits, for both the request vector and the service vector. Also, in this example, there are two chips 204 (e.g., chip 0, chip 1) in the drawer scope, indicated by two bits. As can be seen in action 601, the state of the hardware controller with respect to the request vector is all zeros. In the request vector, the four bits in the chip scope are all zeros because no other shared cache 206 in the same chip 204 (e.g., chip 0) is requesting access to the cache line. Also, in the request vector, the two drawer scope bits are all zero because no other chips are requesting access to the cache line.

[0056] However, in the chip scope of the service vector, the first bit (i.e., the left-most bit) corresponding to shared cache L30 is set to one ("1") since shared cache L30 is being serviced (i.e., accessing a cache line of the particular shared cache) in action 601, meaning that the hardware controller 350 of shared cache L30 is controlling access to the cache line. The remaining service bits in the chip scope of the service vector are zero because other shared caches 206 in the same chip 204 (e.g., chip 0) have not been previously serviced, meaning that other shared caches 206 (e.g., L31, L32, L33) do not have access to the cache line through their respective hardware controllers 350. In the drawer scope of the service vector, the first bit, which is the left-most bit, is set to one ("1") since the corresponding chip 204, which is chip 0, is being serviced. The remaining service bits in the drawer scope of the service vector are set to zero since no other chips 204 (e.g., chip 1) in the same drawer 202 (e.g., drawer 0) are being serviced. If there were multiple drawers in this example, the system scope would have a bit set to identify the drawer currently being serviced, which would identify the drawer whose chips are currently being serviced. Since this example shows the first round, the other service bits are zero, but if other caches were being serviced, their respective bits would be one.

[0057] In act 602, the shared cache L32 requests (fetches) the cache line from the controlling hardware controller 350 of the shared cache L30 via the requesting hardware controller 350 of the shared cache L32. The shared cache L32 is now a requester via the requesting hardware controller 350 of the shared cache L32. The controlling hardware controller 350 of the shared cache L30 records the request from the shared cache L32 in the corresponding (L32) bit position of the chip scope of the request vector and denies the request from the shared cache L32. As seen in the request vector, the second bit from the right of the chip scope is now set to one ("1"), indicating that the corresponding shared cache L32 at that bit has requested the cache line of the particular shared cache. Because the controlling hardware controller 350 of the shared cache L30 is still using the cache line, the controlling hardware controller 350 denies the request from the shared cache L32.

[0058] In action 603, the shared cache L33, via the requestor hardware controller 350 of the shared cache L32, requests (fetches) the cache line from the controlling hardware controller 350 of the shared cache L30. The shared cache L33 now becomes another requestor via the requestor hardware controller 350 of the shared cache L33. The controlling hardware controller 350 of the shared cache L30 records the request from the shared cache L33 in the corresponding (L33) bit position of the chip scope of the request vector and denies the request from the shared cache L33. As can be seen in the request vector in action 603, the rightmost bit of the chip scope is now set to one ("1"), indicating that the corresponding shared cache L33 at that bit has requested the cache line of the particular shared cache 206. Because the control hardware controller 350 of the shared cache L30 is still using the cache line, the control hardware controller 350 denies the request from the shared cache L33.

[0059] In action 604, the shared cache L32 again requests the cache line from the controlling hardware controller 350 of the shared cache L30 via the requesting hardware controller 350 of the shared cache L32. In action 605, the shared cache L30 passes the cache line to the shared cache L32 via the controlling hardware controller 350 of the shared cache L30 and via the controlling hardware controller 350 of the shared cache L32. The controlling hardware controller 350 of the shared cache line L30 passes the request vector and service vector for the cache line of the particular shared cache 206 to the requesting hardware controller 350 of the shared cache L32. The hardware controller 350 of the shared cache L32 now becomes the new controlling hardware controller 350. The controlling (L32) hardware controller 350, which is the controlling (L32) hardware controller 350 of the shared cache L32, updates the request bit in the request vector corresponding to the chip-scoped shared cache L32 from 1 to 0 since the shared cache L32 has access to the cache line and there are no more requests being serviced for the shared cache L32. The controlling (L32) hardware controller 350 further updates the service bit in the service vector corresponding to the chip-scoped shared cache L32 from 0 to 1 since the shared cache L32 is being serviced, which means that the shared cache L32 has access / control of the cache line of the particular shared cache via the controlling (L32) hardware controller 350 of the shared cache L32.

[0060] 7A and 7B show block diagrams illustrating an example of maintaining and passing vectors for distributed hot cache line fairness tracking, according to one or more embodiments of the present invention. This exemplary scenario updates and passes vectors off-chip, e.g., passing request and service vectors from one chip 204 to another chip 204, such as from chip 0 to chip 1 of the same drawer 202. Thus, the exemplary scenario illustrates chip scope and drawer scope, but not system scope, for ease of understanding. While this exemplary scenario is for chips of the same drawer, it should be understood that the system scope also applies by analogy to multiple drawers.

[0061] In action 701 (similar to action 601), the shared cache L30 (which is a shared cache 206) has access and / or control of the cache lines of the particular shared cache 206 through the controlling hardware controller 350 of the shared cache L30. The controlling hardware controller 350 has control of the cache lines of the particular shared cache. In this example, as mentioned above, for both the request vector and the service vector, there are four shared caches 206 (e.g., L30, L31, L32, L33) in the chip scope, indicated by four bits. Also, in this example, there are two chips 204 (e.g., chip 0, chip 1) in the drawer scope, indicated by two bits. As can be seen in action 701, the state of the hardware controller for the request vector is all zeros. In the request vector, all four request bits in the chip scope are zero because no other shared cache 206 in the same chip 204 (e.g., chip 0) is requesting access to the cache line. Also, in the request vector, the two drawer-scope request bits are all zero because no other chips are requesting access to the cache line.

[0062] Similar to FIG. 6, in the chip scope of the service vector, the first service bit (i.e., the left-most bit) corresponding to shared cache L30 is set to one ("1") since shared cache L30 is being serviced (i.e., accessing a cache line of the particular shared cache), meaning that the hardware controller 350 of shared cache L30 is controlling access to the cache line of the particular shared cache 206. The remaining service bits in the chip scope of the service vector are zero since the other shared caches 206 of the same chip 204 (e.g., chip 0) have not been previously serviced, meaning that the other shared caches 206 (e.g., L31, L32, L33) do not have access to the cache line through their respective hardware controllers 350 of the other shared caches 206. In the drawer scope of the service vector, the first service bit, which is the left-most bit, is set to one ("1") since the corresponding chip 204, which is chip 0, is being serviced. The remaining service bits in the drawer scope of the service vector are set to zero since no other chips 204 (e.g., chip 1) in the same drawer 202 (e.g., drawer 0) are being serviced. If there were multiple drawers in this example, the system scope would have a bit set to identify the drawer currently being serviced, which would identify the drawer whose chips are currently being serviced. Since this example shows the first round, the other service bits are zero, but if other caches were being serviced, their respective service bits would be one.

[0063] 7A, in action 702, shared cache L33 requests (fetches) a cache line from the controlling hardware controller 350 of shared cache L30 on chip 0 via the requesting hardware controller 350 of shared cache L33 on chip 0. Shared cache L33 is now a requestor via the requesting hardware controller 350 of shared cache L33. The controlling hardware controller 350 of shared cache L30 records the request from shared cache L33 in the corresponding (L33) bit position of the chip scope of the request vector and denies the request from shared cache L33. As can be seen in the chip scope of the request vector in action 702, the right-most request bit is now set to one ("1"), indicating that the corresponding shared cache L33 at that bit has requested the cache line of the particular shared cache 206. Because the control hardware controller 350 of the shared cache L30 is using the cache line, the control hardware controller 350 denies the request from the shared cache L33.

[0064] In action 703, chip 1, via the requestor hardware controller 350 of chip 1's shared cache 206, requests a cache line of a particular shared cache from the controlling hardware controller 350 of chip 0's shared cache L30. Chip 1 now becomes another requestor on another chip 204 via the requestor hardware controller 350 of chip 1's shared cache. The controlling hardware controller 350 of the shared cache L30 records the request from chip 1 in the corresponding (chip 1) request bit position of the drawer scope of the request vector and denies the request from chip 1 because the chip scope request bit is set. The request bit being set (i.e., "1") in the chip scope of the request vector indicates that there is another shared cache 206 (i.e., shared cache L33) on the same chip 204 (i.e., chip 0) as the controlling shared cache 206 (i.e., shared cache L30) that is requesting a cache line and should be granted the cache line before the higher scope request. In the hierarchy, the chip scope is lower than the drawer scope, which is lower than the system scope. Thus, requesters are processed from the lowest scope to the highest scope. As seen in action 703, the second bit from the left is set to one ("1"), indicating that the corresponding chip 1 (which is chip 204) at that bit's location has requested a cache line in a particular shared cache 206. Because the request bit is set in the chip scope of the request vector, and the control hardware controller 350 of the shared cache L30 is still using the cache line, the control hardware controller 350 denies the request from chip 1.

[0065] In action 704, the shared cache L33 (in chip 0) again requests the cache line from the controlling hardware controller 350 of the shared cache L30 (in the same drawer and same chip 0) via the requesting hardware controller 350 of the shared cache L33. In action 705, the shared cache L30 passes the cache line to the shared cache L33 via the controlling hardware controller 350 of the shared cache L30 and via the requesting hardware controller 350 of the shared cache L33. The controlling hardware controller 350 of the shared cache line L30 passes the request vector and service vector for the cache line of the particular shared cache 206 to the requesting hardware controller 350 of the shared cache L33 in addition to passing access and / or control to the cache line. The hardware controller 350 of the shared cache L33 now becomes the controlling hardware controller 350. The control (L33) hardware controller 350, which is the control (L33) hardware controller 350 for the shared cache L33, updates the request bit in the chip scope of the request vector corresponding to the shared cache L33 (the shared cache L33 itself) from 1 to 0 since the shared cache L33 now has access to the cache line and there are no more requests being serviced for the shared cache L33. The control (L33) hardware controller 350 further updates the service bit in the chip scope of the service vector corresponding to the shared cache L33 from 0 to 1 since the shared cache L33 is being serviced, which means that the shared cache L33 has access / control of the cache line of the particular shared cache via the control (L33) hardware controller 350 for the shared cache L33. Setting the service bit in the chip scope of the service vector for the shared cache L33 prevents the shared cache L33 from receiving access / control of the cache line again before another requester that is waiting in line.The request bit and service bit for shared cache L33 are the rightmost bits of the respective chip scope of the request vector and service vector, respectively.

[0066] In act 706, Chip 1 again requests the particular shared cache cache line from the controlling hardware controller 350 of Chip 0's shared cache L33 via the requesting hardware controller 350 of Chip 1's shared cache 206.

[0067] In action 707, the shared cache L33 passes the cache line to chip 1 (via the requestor hardware controller 350 of chip 1) via the controlling hardware controller 350 of the shared cache L33 and zeros out the chip scope bits / vectors of both the request vector and the service vector. The previous chip scope bits (i.e., chip scope vectors) of the request vector and the service vector were maintained for chip 0, but now the chip scope of the request vector and the service vector are tracked for chip 1. As mentioned above, the controlling hardware controller 350 of the shared cache line L33 passes the request vector and the service vector for the particular shared cache 206 cache line, in addition to passing access and / or control of the cache line to the requestor hardware controller 350 of chip 1. Chip 1 installs (i.e., stores) the cache line in the shared cache L32 of chip 1. The requesting hardware controller 350 for shared cache L32 now becomes the controlling hardware controller 350 for the cache line (for the particular shared cache 206). The controlling (chip 1's L32) hardware controller 350 for shared cache L32 now updates the request bit in the drawer scope of the request vector that corresponds to chip 1 (chip 1 itself) from 1 to 0 because chip 1 has access to the cache line and there are no more requests being serviced by chip 1 (e.g., for each shared cache 206 on chip 1, there may still be requests that are not being serviced by the other hardware controllers 350, but chip 1 now has drawer authority for the cache line and does not need to ask other chips for service).The control (L32 on chip 1) hardware controller 350 further updates the service bit corresponding to the shared cache L32 in the chip scope of the service vector from 0 to 1 since the shared cache L32 on chip 1 is being serviced, meaning that the shared cache L32 has access / control of the cache line of the particular shared cache via the control (L32 on chip 1) hardware controller 350 of the shared cache L32. Setting the service bit in the chip scope of the service vector of the shared cache L32 prevents the shared cache L32 from receiving access and / or control of the cache line again before another requester that is waiting in line. The request bit and service bit for the shared cache L32 are the third bit from the left in the chip scope of the request vector and service vector, respectively. The request bit and service bit for chip 1 are the second bit from the left, respectively.

[0068] Although the system scope is not shown in Figures 7A and 7B, when a request is received from a different drawer 202 (e.g., drawer 2), the following must be true in order to grant the shared cache line to the other drawer 202: all of the lower-scope request vectors must be empty, which means that neither the chip-scope vector nor the drawer-scope vector has the request bit set.

[0069] FIG. 8 is a flowchart of a computer-implemented process 800 of a distributed hot cache line fairness tracking mechanism for accessing cache lines of a shared cache in accordance with one or more embodiments of the present invention. The computer-implemented process 800 may be executed by a hardware controller 350 of each shared cache 206 of any chip 204 in any drawer 202. As will be appreciated by those skilled in the art, each shared cache 206 includes its own hardware controller 350 for accessing cache lines. The hardware controller 350 includes logic 320 and memory 322 for operation, along with other suitable circuitry, in accordance with one or more embodiments of the present invention. In accordance with one or more embodiments, the memory 322 of each hardware controller 350 may be utilized to store request vectors and service vectors for cache lines of a particular shared cache 206, and the request vectors and service vectors may be utilized to control access to the cache lines of a particular shared cache 206. For purposes of discussion, a hardware controller that has access and / or control of a cache line is referred to as a controlling hardware controller, while a hardware controller that is requesting access and / or control of a cache line is referred to as a requesting hardware controller (i.e., requestor), without limitation. A controlling hardware controller controls a cache line in its shared cache 206, while a requesting hardware controller is requesting control of a cache line in its shared cache 206, which may be in the same chip 204, different chips 204 in the same drawer 202, or different drawers 202 in the system 200, or a combination thereof.

[0070] In block 802, the controlling hardware controller 350 having control of a cache line in a particular shared cache 206 is configured to receive a remote snoop of a cache line from a requesting hardware controller 350 for a second shared cache 206. A remote snoop is a fetch request that seeks access and / or control of a cache line in the first shared cache 206.

[0071] In block 804, the control hardware controller 350 is configured to check whether the control hardware controller 350 has the authority to grant the cache line to the remote snoop. The control hardware controller 350 may have a global / system coherency authority, a drawer coherency authority, or a chip coherency authority, or a combination thereof, as mentioned above. The global / system coherency authority is the global intervention master (GIM). The GIM of the cache line is the drawer intervention master (DIM) of the drawer of the cache line and the chip intervention master (CIM) of the chip of the cache line. The drawer coherency authority (DIM) is the highest level of authority for the cache line in the drawer. The chip coherency authority (CIM) of the cache line is the highest level of authority for the cache line in the chip.

[0072] In block 806, if the controlling hardware controller 350 does not have permission to grant the remote snoop a cache line of the particular shared cache 206, the controlling hardware controller 350 does not allow the remote snoop and does not coherently reject the remote snoop. In other words, the controlling hardware controller 350 does not allow the fetch request, and therefore the requesting hardware controller 350 is not allowed to access the cache line of the particular shared cache 206. No changes are made to the request vector and the service vector.

[0073] In block 808, if the controlling hardware controller 350 does in fact have the authority to allow / authorize the requesting hardware controller 350 to remotely snoop on a cache line of the particular shared cache 206, the controlling hardware controller 350 is configured to check whether the remote snoop has already been serviced. The controlling hardware controller 350 may, for example, check the chip scope, drawer scope, and system scope of a service vector in the memory 322 of the controlling hardware controller 350 to determine whether the same requesting hardware controller 350 (e.g., representing a shared cache 206 of the same chip 204, another chip 204 of the same drawer 202, or another drawer 202 of the system 200, or a combination thereof, respectively) has previously been granted access to the cache line of the particular shared cache 206 by a previous fetch request. If the request from the requesting hardware controller 350 is for an on-chip shared cache 206, the controlling hardware controller 350 checks the corresponding bit position in the chip scope of the service vector to determine if the service bit for the corresponding shared cache 206 is set (i.e., is a "1" meaning that access to the cache line was previously granted). If the request from the requesting hardware controller 350 is for another chip in the same drawer 202 (i.e., an off-chip shared cache 206), the controlling hardware controller 350 checks the corresponding bit position in the drawer scope of the service vector to determine if the service bit for the corresponding chip 204 (e.g., chip 0, chip 1, chip 2) is set (i.e., is a "1" meaning that access to the cache line was previously granted).If the request from the requesting hardware controller 350 is for another drawer 202 in the system 200 (i.e., the shared cache 206 of another drawer 202 in the system 200), the controlling hardware controller 350 checks the corresponding bit position in the system scope of the service vector to determine whether the service bit for the corresponding drawer 202 (e.g., Drawer 0, Drawer 1, Drawer 2) is set (i.e., is "1", meaning that access to the cache line was previously granted).

[0074] In block 810, if the requesting hardware controller 350 has already been granted access to the cache line in the particular shared cache 206 (yes), the controlling hardware controller 350 denies the remote snoop and retries later.

[0075] At block 812, if the requesting hardware controller 350 has not previously been granted access to the cache line in the particular shared cache 206 (NO), the controlling hardware controller 350 is configured to check whether the (controlling) shared cache 206 is in a state to process this remote snoop request. Some examples of reasons why the (controlling) shared cache 206 cannot process the request may include lacking the resources required to process the request, not completing the placement of the cache line, or in the process of transferring the cache line to another cache.

[0076] At block 814, if the controlling hardware controller 350's (controlling) shared cache 206 is ready to process the remote snoop request (yes), the controlling hardware controller 350 is configured to check whether there are any unserviced requests in the request vector that are of a lower scope than the current remote snoop request from the requesting hardware controller 350. As mentioned herein, there are three exemplary scopes: chip scope (lowest scope) of shared caches 206 of the same chip (e.g., L30, L31, L32, L33), drawer scope (next highest scope) of chips 204 of the same drawer 202 (e.g., chip 0, chip 1, chip 2), and system scope (highest scope) of drawers 202 of the system 200 (e.g., drawer 0, drawer 1, drawer 2). If no request bits are set in the request vector for any scopes lower than the scope / level of the remote snoop request, flow proceeds to block 816.

[0077] For example, if the request bit is set in the chip scope (i.e., the lowest scope) of the request vector, then in order to be granted access to the cache line, the current remote snoop request must be for an on-chip shared cache 206, which means that the current remote snoop must be for another shared cache on the same chip as the shared cache 206 of the controlling hardware controller 350 (which it controls).

[0078] If the request bit is set in the drawer scope (i.e., the next higher scope) of the request vector, then in order to be granted access to the cache line, the current remote snoop request must be for a chip 204 in the same drawer 202 or for a shared cache 206 in the chip 204, which means that the current remote snoop must be for another chip 204 (with a shared cache) in the same drawer 202 as the shared cache 206 (that it controls) of the controlling hardware controller 350, or the current remote snoop must be for another shared cache in the same chip as the shared cache 206 (that it controls) of the controlling hardware controller 350.

[0079] In block 816, the controlling hardware controller 350 is configured to allow the snoop request from the requesting hardware controller 350. The controlling hardware controller 350 is also configured to reset the lower scope vectors / bits of the request and service vectors, transfer the request and service vectors in the memory 322 of the controlling hardware controller 350 to the requesting hardware controller 350, and retire the controlling hardware controller 350 (itself). The lower scope vectors / bits are the request and service bits that are lower than the level of the request made by the requester. The levels of requests from the lowest to the highest may be for a shared cache of the same chip as the requesting hardware controller 350 of the shared cache 206 (that it controls), a next highest request for a chip 204 of the same drawer 202, and a highest request for another drawer 202 of the system 200. Upon granting the request and forwarding the request vector and service vector, the requesting hardware controller 350 becomes the new controlling hardware controller 350 and continues to maintain the request vector and service vector for the cache line of the particular shared cache 206 .

[0080] If (at block 812) the shared cache 206 is not in a state to process the remote snoop request (no) or (at block 814) there are lower scope requests in the request vector that have not yet been serviced (yes), then at block 818 the control hardware controller 350 is configured to set a request bit position / location in the request vector for the remote request. The control hardware controller 350 is configured, for example, to set (i.e., "1") a chip scope request bit position / location in the request vector if the remote request is from an on-chip shared cache, set a drawer scope request bit position / location in the request vector if the remote request is from another chip (i.e., off-chip), set a system scope request bit position / location in the request vector if the remote request is from another drawer, or a combination thereof. Flow from block 818 proceeds to block 810, discussed above.

[0081] The hardware controller 350, according to one or more embodiments, can have a timeout mechanism to prevent a requester's progress in gaining access to a cache line of a particular shared cache from being delayed due to fairness. The timeout mechanism is implemented to help in situations where a previously unsuccessful requester takes too long to return and re-request the cache line. For example, a timeout counter, such as counter 342, begins counting down when a local shared cache (L3 cache) that has access to the cache line indicates that it is ready to service a snoop request and is retaining access to the cache line only to pass the fairness vector to the next requester. If the next requester does not come forward to request the line before the timeout counter reaches zero, the fairness vector (i.e., both the request vector and the service vector for that cache line) is cleared.

[0082] Using a distributed hot cache line fairness tracking mechanism according to one or more embodiments provides various technical solutions and advantages. Techniques for ensuring cache line fairness include a request vector and a service vector for each active cache line, where a request bit is set when a fetch is rejected, a service bit is set when the cache line is given to a new requester, or a fetch from a requester with the service bit set is rejected, or a combination of these. Technical solutions and advantages for ensuring cache line fairness include a request vector having a request bit representing a requester at a lower scope and a request bit representing a group of requesters at a higher scope, and if a requester at a lower scope has a request bit set in the request vector and the corresponding service bit at the lower scope is not set in the service vector, the requester at the higher scope is rejected. The request bit in the request vector is set only if the requester becomes an intervention master at the scope of the incoming request. A hierarchy is established whose scopes include chip scope, drawer scope, and system scope. The request and service vectors are maintained by a local fetch controller (i.e., the controlling hardware controller), which stays alive as long as the request vector has a request bit set and the corresponding bit in the service vector is not set, and the local fetch controller is retired once the fetch (request) has been serviced. A local fetch controller that stays alive only to wait to pass the vector to the next requester (i.e., the controller is ready to service the request) can be retired after (1) the controller communicates the vector or (2) a timeout limit is reached. The request and service vector values ​​are sent as part of the data transfer for the fetch (request), and the lower-scope bits in the request and service vectors are cleared when the cache line is transferred to the higher scope.

[0083] 9 is a flowchart of a computer-implemented method 900 for implementing a distributed hot cache line fairness tracking mechanism with respect to hot cache lines of the shared cache 206, according to one or more embodiments. Reference may be made to any of the figures discussed herein.

[0084] In block 902, the control hardware controller 350 is configured, in response to receiving an incoming request to access a cache line (of a particular shared cache 206), to make a decision to grant access to the cache line based on a request state (e.g., the request vector of FIG. 4, 5A, 5B, 5C) and a service state (e.g., the service vector of FIG. 4, 5A, 5B, 5C) associated with the cache line (of the particular shared cache 206) and used to maintain the cache line, the structure including the request state and the service state. In block 904, the control hardware controller 350 is configured, in response to the decision to grant access to the cache line, to transfer the request state (e.g., the request vector of FIG. 4, 5A, 5B, 5C) and the service state (e.g., the service vector of FIG. 4, 5A, 5B, 5C) together with the data of the cache line (of the particular shared cache 206).

[0085] The request state and service state (e.g., request vector and service vector) are forwarded to a controller making the incoming request (e.g., requesting hardware controller 350). The control hardware controller 350 is configured to receive the incoming request. The request state and service state are forwarded from memory 322 of the control hardware controller 350 that received the incoming request. The request state (e.g., request vector) is configured to track requests to access a cache line that have been observed but not allowed. The service state is configured to track requests to access a cache line that have been observed and that have been allowed to access the cache line. The request state and service state are configured to be forwarded to multiple controllers of a computing environment (e.g., system 200, which may represent a portion of a cloud).

[0086] A first portion of the structure is configured to track a first requestor of a first scope, and a second portion of the structure is configured to track a second requestor of a second scope, the first scope and the second scope having a hierarchical relationship. For example, a chip scope and a drawer scope are in a hierarchical relationship, where the chip scope tracks the first requestor and the drawer scope tracks the second requestor, or the chip scope, the drawer scope, and the system scope are in a hierarchical relationship, where the chip scope tracks the first requestor, the drawer scope tracks the second requestor, and the system scope tracks a third requestor.

[0087] A first entry in the structure is configured to track request and service states for a first cache, and a second entry in the structure is configured to track other request and service states for a second cache. The controller 350 can have multiple entries in the structure, as shown in FIG. 4, for example, to track cache lines for different caches. Each cache line in the cache has its own entry, including a request vector and a service vector. The structure can have a request structure (e.g., a data structure for a request vector) for tracking request states, and a service structure (e.g., a separate data structure for a service vector) for tracking service states.

[0088] 10 is a flowchart of a computer-implemented method 1000 for implementing a distributed hot cache line fairness tracking mechanism with respect to hot cache lines of a shared cache 206, according to one or more embodiments. Reference may be made to any of the figures discussed herein.

[0089] In block 1002, the controlling hardware controller 350 is configured, in response to receiving an incoming request from a requestor (e.g., the requesting hardware controller 350) to access a cache line (of a particular shared cache 206), to make a decision to deny access to the cache line based on a request state (e.g., the request vector of FIG. 4, FIG. 5A, FIG. 5B, FIG. 5C) and a service state (e.g., the service vector of FIG. 4, FIG. 5A, FIG. 5B, FIG. 5C) used to maintain the cache line (of a particular shared cache 206), the structure including the request state and the service state. In block 1004, the controlling hardware controller 350 is configured, in response to the decision to deny access to the cache line, to set a (request) bit in the request state (e.g., the request vector), the bit corresponding to the requestor (e.g., the requesting hardware controller 350). In block 1006, the control hardware controller 350 is configured to, in response to receiving another incoming request to access the cache line from a requestor (e.g., the same requestor hardware controller 350), make another decision to grant access to the cache line for the other incoming request based on the (request) bit set in the request state (e.g., the request vector) and the service state. In block 1008, the control hardware controller 350 is configured to forward the request state and service state (e.g., the request vector and the service vector) to the requestor along with the data for the cache line.

[0090] The request state and service state are transferred from the controlling hardware controller 350 that received the incoming request to the requesting hardware controller 350 that sent the incoming request. The decision to deny access to a cache line is based on the value of the request state set in a scope that is lower than another scope associated with the requestor.

[0091] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementations of the teachings described herein are not limited to cloud computing environments. Rather, embodiments of the invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0092] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing power, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0093] Its features are as follows. On-Demand Self-Service: Cloud customers can unilaterally provision computing capacity, such as server time and network storage, as needed, automatically and without the need for human interaction with the service provider. Broad network access: Functionality is available across the network and accessed through standard mechanisms, facilitating use from heterogeneous thin-client or thick-client platforms (e.g., cell phones, laptops, and PDAs). Resource Sharing: The provider's computing resources are shared to serve multiple consumers using a multi-tenant model with various physical and virtual resources dynamically allocated and reallocated on demand. Customers generally have no control over or knowledge of the exact location of the resources provided, but the experience is location-independent in that they may be able to identify the location at a more abstract level (e.g., country, state, or data center). Rapid scalability: Capabilities can be quickly and elastically provisioned, in some cases automatically, to quickly scale out and quickly release to quickly scale in. To the consumer, the capabilities available for provisioning often appear unlimited, and can be purchased in any quantity at any time. Services are meterable: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of management appropriate to the type of service (e.g., storage, processing power, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services being used.

[0094] The service model is as follows: Software as a Service (SaaS): The functionality offered to the consumer is the use of the provider's applications running on the cloud's infrastructure. The applications are accessible from a variety of client devices through thin client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, except for possibly limited user-specific application configuration settings. Platform as a Service (PaaS): The functionality offered to the customer is the implementation of applications created or acquired by the customer, written using programming languages ​​and tools supported by the provider, on the cloud's infrastructure. The customer does not manage or control the underlying cloud's infrastructure, including the network, servers, operating systems, or storage, but has control over the implemented applications and, in some cases, the configuration of the environment that hosts the applications. Infrastructure as a Service (IaaS): The capability provided to a customer is to provision processing power, storage, network, and other underlying computing resources on which the customer can deploy and run any software, which may include operating systems and applications. The customer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and in some cases, limited control over selected networking components (e.g., host firewalls).

[0095] The implementation model is as follows: Private Cloud: The cloud infrastructure is operated solely for one organization. The cloud infrastructure may be managed by the organization or a third party and may be on-premise or off-premise. Community Cloud: The cloud infrastructure is shared by multiple organizations to support a community with shared concerns (e.g., mission, security requirements, policies, regulatory compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may reside on-premise or off-premise. Public Cloud: The cloud infrastructure is available to the general public or large industry groups and is owned by an organization that sells cloud services. Hybrid Cloud: A cloud infrastructure consists of two or more clouds (private, community, or public) that remain their own entities but are bound together by standardized or proprietary technologies that make data and applications mobile (e.g., cloud bursting for load balancing between clouds).

[0096] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that consists of a network of interconnected nodes.

[0097] 11, an exemplary cloud computing environment 50 is shown. The cloud computing environment 50, as shown, comprises one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, can communicate. The nodes 10 can communicate with each other. The nodes can be physically or virtually grouped in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described herein above (not shown). The cloud computing environment 50 allows the cloud consumers to provide infrastructure, platform, and / or software as a service without the need to maintain resources on local computing devices. It should be understood that the types of computing devices 54A-N shown in FIG. 11 are intended as examples only, and that the computing node 10 and cloud computing environment 50 can communicate with any type of computerized device through any type of network or network-addressable connection (e.g., using a web browser), or both.

[0098]

[0071] Referring now to Figure 12, there is shown a set of functional abstraction layers provided by cloud computing environment 50 (Figure 11). It should be understood in advance that the components, layers, and functions shown in Figure 12 are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0099] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61, RISC (Reduced Instruction Set Computer) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. Software components, in some embodiments, include network application server software 67 and database software 68. The hardware components, in one or more embodiments, may include the system 200 discussed herein, including hardware controller 350.

[0100] The virtualization layer 70 provides an abstraction layer that can provide examples of the following virtual entities: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0101] The management layer 80, in one example, may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of such resources. Such resources may include application software licenses, in one example. Security provides identity verification of cloud consumers and tasks as well as protection of data and other resources. User portal 83 provides consumer and system administrator access to the cloud computing environment. Service level management 84 provides allocation and management of cloud computing resources such that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-arrangement and procurement of cloud computing resources for anticipated future requirements according to SLAs.

[0102] The workload tier 90 provides examples of functions that can utilize a cloud computing environment. Examples of workloads and functions that may be provided by this tier include mapping and navigation 91, software development and lifecycle management 92, instructional delivery in virtual classrooms 93, data analytics processing 94, transaction processing 95, and workloads and functions 96.

[0103] FIG. 13 is a block diagram of a system 1300 according to an embodiment of the invention. The system 1300 includes a processing circuit 1310 that is used to generate a design 1330 that is ultimately manufactured into an integrated circuit 1320 (e.g., chip 204) that uses a distributed hot cache line fairness tracking mechanism. The steps involved in manufacturing the integrated circuit 1320 are well known and will be briefly described herein. Once the physical layout 1340 is completed, based in part on being configured to use a distributed hot cache line fairness tracking mechanism according to an embodiment of the invention, the completed physical layout 1340 is provided to a foundry. Based on the completed physical layout, masks are generated for each layer of the integrated circuit. The wafer is then processed in a mask order sequence. Processing includes photolithography and etching, which will be further discussed with reference to FIG. 14.

[0104] FIG. 14 is a process flow of a method for manufacturing an integrated circuit according to an exemplary embodiment of the present invention. Once the physical design data is obtained based in part on the use of a distributed hot cache line fairness tracking mechanism in the chip 204, the integrated circuit 1320 can be manufactured according to a known process generally described with reference to FIG. 14. Typically, a wafer having multiple copies of the final design is manufactured and cut (i.e., diced) so that each die is one copy of the integrated circuit 1320. In block 1410, the process includes manufacturing a mask for lithography based on the final physical layout. In block 1420, manufacturing the wafer includes performing photolithography and etching using the mask. Once the wafer is diced, in block 1430, testing and sorting of each die is performed and defective die are removed.

[0105] Various embodiments of the present invention are described herein with reference to the associated drawings. Alternative embodiments may be devised without departing from the scope of the present invention. Although the following description and drawings describe various connections and relationships between elements (e.g., on top of, under, adjacent to, etc.), those skilled in the art will recognize that many of the relationships described herein are orientation independent, provided that the described functionality is maintained when the orientation is changed. Such connections and / or relationships may be direct or indirect, unless otherwise specified, and the present invention is not intended to be limited in this respect. Thus, coupling between entities may refer to either direct coupling or indirect coupling, and the relationship between entities may be direct or indirect. As an example of an indirect relationship, reference in this description to forming layer "A" on layer "B" includes the situation where one or more intermediate layers (e.g., layer "C") are between layers "A" and "B," so long as the relevant properties and functions of layers "A" and "B" are not substantially altered by the intermediate layers.

[0106] The term "selective," e.g., "a first element is selective to a second element," means that the first element can be etched and the second element can act as an etch stop.

[0107] As used herein, "p-type" refers to the addition of impurities to an intrinsic semiconductor that create a deficiency of valence electrons. In silicon-containing substrates, examples of p-type dopants, or impurities, include, but are not limited to, boron, aluminum, gallium, and indium.

[0108] As used herein, "n-type" refers to the addition of impurities that provide free electrons to an intrinsic semiconductor. In silicon-containing substrates, examples of n-type dopants, or impurities, include, but are not limited to, antimony, arsenic, and phosphorus.

[0109] As previously mentioned herein, for the sake of brevity, the present specification may or may not describe in detail the prior art related to the manufacturing methods of semiconductor devices and integrated circuits (ICs). However, by way of background, a more general description of the semiconductor device manufacturing process that may be utilized in practicing one or more embodiments of the present invention will now be presented. While the specific manufacturing steps utilized in practicing one or more embodiments of the present invention may be individually known, the combination of steps described and / or the resulting structures of the present invention are unique. Thus, the unique combination of steps described in connection with the manufacturing method of semiconductor devices according to the present invention utilizes various individually known physical and chemical processes performed on a semiconductor (e.g., silicon) substrate, some of which are described in the paragraphs immediately below.

[0110] The various processes used to form the microchips that will be packaged into ICs are generally divided into four general categories: film deposition, removal / etching, semiconductor doping, and patterning / lithography. Deposition is any process that grows, coats, or otherwise transfers material onto a wafer. Available techniques include physical vapor deposition (PVD), chemical vapor deposition (CVD), electrochemical deposition (ECD), molecular beam epitaxy (MBE), and more recently atomic layer deposition (ALD), among others. Removal / etching is any process that removes material from the wafer. Examples include etching processes (wet or dry) and chemical-mechanical planarization (CMP). Semiconductor doping is the modification of electrical properties, for example by doping the source and drain of a transistor, usually by diffusion or ion implantation, or both. These doping processes are followed by furnace annealing or rapid thermal annealing (RTA). The annealing serves to activate the implanted dopants. Both conductor (e.g., polysilicon, aluminum, copper, etc.) and insulator (e.g., various forms of silicon dioxide, silicon nitride, etc.) films are used to connect and insulate transistors and their components. By selectively doping different regions of a semiconductor substrate and applying voltages, the conductivity of the substrate can be altered. By creating structures of these various components, millions of transistors can be constructed and wired together to form the complex circuits of modern microelectronic devices.

[0111] Atomic layer etching processes, as mentioned above, can be used in the present invention to remove via residues, such as those that may result from via misalignment. Atomic layer etching processes use plasma-based or electrochemical techniques to perform precise etching of metals. Atomic layer etching processes are generally defined by two well-defined sequential self-limiting reaction steps that can be controlled separately. The process generally involves passivation followed by selective removal of the passivation layer and can be used to remove metal layers as thin as a few nanometers. Exemplary plasma-based techniques generally include a two-step process that generally involves exposing metals, such as copper, to chlorine and hydrogen plasmas at low temperatures (below 20° C.). This process produces volatile etch products that minimize contamination of the surface. In another example, periodic exposure to oxidizing agents and hexafluoroacetylacetone (Hhfac) at high temperatures, such as 275° C., can be used to selectively etch metals, such as copper. Exemplary electrochemical techniques can also include two steps. The first step involves limited surface sulfurization of a metal, such as copper, to form a metal sulfide, e.g., Cu2S, followed by selective wet etching of the metal sulfide (e.g., etching of Cu2S with HCl). Atomic layer etching is a relatively recent technology, and optimization for a particular metal is well within the skill of one of ordinary skill in the art. Reaction at the surface allows for high selectivity, with minimal or no attack of exposed dielectric surfaces.

[0112] Semiconductor lithography is the formation of a three-dimensional relief image or pattern on a semiconductor substrate and then the transfer of the pattern into the substrate. In semiconductor lithography, the pattern is formed by a light-sensitive polymer called a photoresist. The steps of lithography and etching pattern transfer are repeated multiple times to build the complex structures that make up the transistors, and the numerous wires that connect the millions of transistors in a circuit. Each pattern printed on the wafer is aligned to the previously formed patterns, and conductors, insulators, and selectively doped regions are slowly built up to form the final device.

[0113] Photoresist can be formed using conventional deposition techniques such as chemical vapor deposition, plasma vapor deposition, sputtering, dip coating, spin-on coating, brushing, spraying, or other similar deposition techniques. After formation of the photoresist, the photoresist is exposed to a desired pattern of radiation such as x-ray radiation, extreme ultraviolet (EUV) radiation, electron beam radiation, or the like. The exposed photoresist is then developed utilizing a conventional resist development process.

[0114] After the developing step, an etching step can be performed to transfer the pattern from the patterned photoresist to the interlayer dielectric. The etching step used in forming the at least one opening can include a dry etching process (including, for example, reactive ion etching, ion beam etching, plasma etching, or laser ablation), a wet chemical etching process, or any combination thereof.

[0115] For the sake of brevity, the prior art relevant to making and using aspects of the present invention may or may not be described in detail herein. In particular, various aspects of computing systems and specific computer programs that perform various technical functions described herein are well known. Thus, for the sake of brevity, details of many conventional implementations are only mentioned briefly herein or omitted entirely, without presenting details of well-known systems and / or processes.

[0116] In some embodiments, various functions or actions may be performed at a particular location, or in conjunction with the operation of one or more devices or systems, or both. In some embodiments, some of the particular functions or actions may be performed at a first device or location, and the remaining functions or actions may be performed at one or more additional devices or locations.

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

[0118] The equivalents of the corresponding structures, materials, acts, and all means or steps and functional elements in the following claims are intended to include any structures, materials, or acts for performing a function in combination with other elements recited in the claims, specifically as recited in the claims. The present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the present disclosure. The embodiments were selected and described in order to best explain the principles and practical applications of the present disclosure, and to enable others skilled in the art to understand the present disclosure in terms of various embodiments with various modifications as suited to the particular uses contemplated.

[0119] The diagrams depicted herein are exemplary. There may be many variations in the diagrams or the steps (or operations) described therein without departing from the spirit of the disclosure. For example, actions may be performed in a different order, actions may be added, deleted, or modified, and the term "coupled" describes that there is a signal path between two elements, and does not imply a direct connection between the elements without an intervening element / connection between the elements. All such variations are considered part of the disclosure.

[0120] The following definitions and abbreviations are to be used to interpret the claims and the specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," or "containing," or other variations thereof, are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or device that includes a list of elements is not necessarily limited to only those elements, but can include other elements not expressly listed or inherent in such composition, mixture, process, method, article, or device.

[0121] Moreover, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" should be understood to include any integer number greater than or equal to one, i.e., 1, 2, 3, 4, etc. The term "multiple" should be understood to include any integer number greater than or equal to two, i.e., 2, 3, 4, 5, etc. The term "connected" can include both indirect and direct "connections."

[0122] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with the measurement of a particular quantity based on the equipment available at the time of filing. For example, "about" can include a range of ±8%, 5%, or 2% of a particular value.

[0123] The present invention may be a system, method, or computer program product incorporating any possible level of technical detail, or a combination thereof. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform aspects of the present invention.

[0124] A computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures in grooves on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires, should not be construed as being ephemeral signals in and of themselves.

[0125] The computer readable program instructions described herein can be downloaded from the computer readable storage medium to the respective computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface of each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage in the computer readable storage medium within the respective computing / processing device.

[0126] The computer readable program instructions for carrying out the operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or object-oriented programming languages, such as Smalltalk, C++, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed completely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In a scenario executed on a remote computer or server, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to dedicate the electronic circuitry to perform aspects of the invention.

[0127] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0128] Such computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. Such computer readable program instructions may also be stored on a computer readable storage medium, such that the computer readable storage medium on which the instructions are stored has an article of manufacture including instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0129] The computer readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device, causing the computer, other programmable apparatus, or other device to perform a series of operational steps to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0130] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block of the flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions shown in the blocks may be performed out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in the reverse order, depending on the functionality required. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations of blocks in the block diagrams and / or flow diagrams, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that perform the specified functions or actions.

[0131] The description of various embodiments of the present invention has been given for illustrative purposes, and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification are selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to allow other skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method, comprising: in response to receiving an incoming request to access a cache line, making a decision to grant access to the cache line based on a request state and a service state associated with the cache line, the granting decision structure including the request state and the service state; in response to the determination granting access to the cache line, transferring the request state and the service state along with data for the cache line; A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the request state and the service state are forwarded to a controller making the incoming request.

3. The computer-implemented method of claim 1 , wherein a controller is configured to receive the incoming request.

4. The computer-implemented method of claim 1 , wherein the request state and the service state are transferred from a controller that received the incoming request.

5. the request state is configured to track requests to access the cache line that are observed but not authorized; and and configured to track requests to access the cache line where the service state is observed and where access to the cache line is permitted.

2. The computer-implemented method of claim 1.

6. 2. The computer-implemented method of claim 1, wherein a first portion of the structure is configured to track a first requestor of a first scope, and a second portion of the structure is configured to track a second requestor of a second scope, the first scope and the second scope having a hierarchical relationship.

7. 2. The computer-implemented method of claim 1, wherein a first entry of the structure is configured to track the request state and the service state of a first cache and a second entry of the structure is configured to track other request states and service states of a second cache.

8. 2. The computer-implemented method of claim 1, wherein the structures include a request structure for tracking the request state and a service structure for tracking the service state.

9. in response to receiving an incoming request to access a cache line from a requestor, making a decision to deny access to the cache line based on a request state and a service state associated with the cache line, the decision to deny including the request state and the service state; setting a bit in the request state in response to the decision to deny access to the cache line, the bit corresponding to the requestor; in response to receiving another incoming request for access to the cache line from the requestor, making another decision to grant access to the cache line to the other incoming request based on the bit set in the request state and the service state; forwarding said request state and said service state along with said cache line data to said requestor; 2. The computer-implemented method of claim 1, comprising:

10. 10. The computer-implemented method of claim 9, wherein the requestor is a controller, and the controller makes the incoming request.

11. 10. The computer-implemented method of claim 9, wherein the decision to deny access to the cache line is based on a value set in the request state at a scope that is lower than another scope associated with the requestor.

12. 10. The computer-implemented method of claim 9, wherein the request state and the service state are transferred from a controller that received the incoming request to the requestor that sent the incoming request.

13. 1. A system comprising: A shared cache; a controller coupled to the shared cache; wherein the controller: in response to receiving an incoming request to access a cache line, making a decision to grant access to the cache line based on a request state and a service state associated with the cache line, a structure including the request state and the service state; and In response to the decision to grant access to the cache line, the request state and the service state are transferred along with the data of the cache line. The system is configured as follows.

14. The system of claim 13 , wherein the request state and the service state are transferred to another controller that services the incoming request.

15. The system of claim 13 , wherein the controller is configured to receive the incoming request.

16. The system of claim 13 , wherein the request state and the service state are transferred from the controller that received the incoming request to another controller.

17. the request state is configured to track requests to access the cache line that are observed but not authorized; and and configured to track requests to access the cache line where the service state is observed and where access to the cache line is permitted. The system of claim 13.

18. 14. The system of claim 13, wherein a first portion of the structure is configured to track a first requestor of a first scope and a second portion of the structure is configured to track a second requestor of a second scope, the first scope and the second scope having a hierarchical relationship.

19. 14. The system of claim 13, wherein a first entry of the structure is configured to track the request state and the service state of a first cache and a second entry of the structure is configured to track other request states and service states of a second cache.

20. 14. The system of claim 13, wherein the structures include a request structure for tracking the request state and a service structure for tracking the service state.

21. The controller further comprises: in response to receiving an incoming request to access a cache line from a requestor, making a decision to deny access to the cache line based on a request state and a service state associated with the cache line, a structure including the request state and the service state; in response to said determining to deny access to said cache line, setting a bit in said request state, said bit corresponding to said requestor; in response to receiving another incoming request for access to the cache line from the requestor, making another decision to grant access to the cache line to the other incoming request based on the bit set in the request state and the service state; and forwarding said request state and said service state along with said cache line data to said requestor. The system of claim 13 configured to:

22. A controller, the controller comprising logic, the logic comprising: in response to receiving an incoming request to access a cache line, making a decision to grant access to the cache line based on a request state and a service state associated with the cache line, the granting decision structure including the request state and the service state; in response to the determination granting access to the cache line, transferring the request state and the service state along with data for the cache line; A controller that can perform operations including

23. The controller of claim 22 , wherein the logic is configured to forward the request state and the service state to another controller that sent the incoming request.

24. the request state is configured to track requests to access the cache line that are observed but not authorized; and and configured to track requests to access the cache line where the service state is observed and where access to the cache line is permitted.

23. The controller of claim 22.

25. 23. The controller of claim 22, wherein a first portion of the structure is configured to track a first requestor of a first scope and a second portion of the structure is configured to track a second requestor of a second scope, the first scope and the second scope having a hierarchical relationship.

26. 1. A computer-implemented method, comprising: in response to receiving an incoming request to access a cache line from a requestor, making a decision to deny access to the cache line based on a request state and a service state associated with the cache line, the structure making the denial decision including the request state and the service state; setting a bit in the request state in response to the decision to deny access to the cache line, the bit corresponding to the requestor; in response to receiving another incoming request for access to the cache line from the requestor, making another decision to grant access to the cache line to the other incoming request based on the bit set in the request state and the service state; forwarding said request state and said service state along with said cache line data to said requestor; A computer-implemented method comprising:

27. 27. The computer-implemented method of claim 26, wherein the requestor is a controller, and the controller makes the incoming request.

28. 27. The computer-implemented method of claim 26, wherein the decision to deny access to the cache line is based on a value set in the request state at a scope that is lower than another scope associated with the requestor.

29. 27. The computer-implemented method of claim 26, wherein the request state and the service state are transferred from a controller that received the incoming request to the requestor that sent the incoming request.

30. 1. A system comprising: A shared cache; a controller coupled to the shared cache; wherein the controller: in response to receiving an incoming request to access a cache line from a requestor, making a decision to deny access to the cache line based on a request state and a service state associated with the cache line, a structure including the request state and the service state; in response to said determining to deny access to said cache line, setting a bit in said request state, said bit corresponding to said requestor; in response to receiving another incoming request for access to the cache line from the requestor, making another decision to grant access to the cache line to the other incoming request based on the bit set in the request state and the service state; and forwarding said request state and said service state along with said cache line data to said requestor; The system is configured as follows.

31. 30. A computer program comprising program code means adapted to perform the method according to any of claims 1 to 12 or any of claims 26 to 29, when said computer program is run on a computer.

Images