Memory controller

[0001] A modern computer system comprises a processor, a data store (e.g., a hard drive) and a memory system. The memory system comprises one or more memory modules and a memory controller. While the data store provides a means to store a much greater quantity of data than can be stored in the memory modules, the structure of the memory modules enables the processor to access data from the memory modules more quickly.

[0002] During normal operation of the computer system, and under control of an operating system, the processor causes the memory controller to transfer data between the data store and the memory modules, and between the memory modules and the processor.

[0003] From time-to-time, part or all of a memory module may fail. If the module experiences a catastrophic failure, the memory module may need to be replaced. However, many failures take the form of hard or intermittent failures of a single bit (or small, localized set of bits). Some operating systems respond to these smaller memory failures as if they were larger errors by, for example, de-allocating an entire page of memory locations (i.e., de-allocating much more memory than is necessary to isolate the memory failure). Other operating systems do not respond to memory failures at all, thereby resulting in slower memory response times and/or risking the loss of data.

[0004] Illustrative embodiments of the invention are illustrated in the drawings, in which:

[0005] FIG. 1 illustrates an exemplary computer system comprising an exemplary memory controller;

[0006] FIG. 2 illustrates an exemplary embodiment of a memory cache of the FIG. 1 memory controller; and

[0007] FIG. 3 illustrates an exemplary method for responding to memory failures using, for example, the FIG. 1 memory controller.

[0008] FIG. 1 illustrates an exemplary computer system 100 comprising an exemplary memory controller 102. The memory controller 102 comprises an interface 104 to receive memory read requests and memory write requests (i.e., memory read/write requests) from, for example, a processor 106 that is logically connected to the interface 104. The memory controller 102 also comprises a second interface 108 to read/write data from a number of memory modules 110, 112 that are connected to the interface 108.

[0009] The memory module(s) 110, 112 may take various forms, but will typically comprise printed circuit boards having one or more random access memories (RAMs) mounted thereon. Each of the RAMs provides a plurality of addressable memory locations in which data retrieved from a data store 114 may be temporarily stored for faster access by the processor 106.

[0010] During normal operation of the computer system 100, and under control of an operating system, the processor 106 causes the memory controller 102 to transfer data between the data store 114 and the memory modules 110, 112, and between the memory modules 110, 112 and the processor 106. From the memory controller's perspective, and in terms of the first and second interfaces 104, 108, it receives read/write requests from the processor 106, dispatches the read/write requests to the memory module(s) 110, 112, and returns data that is read from the memory module(s) 110, 112 to the processor 106.

[0011] On occasion, a portion of a memory module may fail. Often, the failure will take the form of a hard or intermittent failure of a single bit (or a small, localized set of bits). However, even when a memory failure is small or localized, a computer's operating system may respond to the failure by de-allocating an entire page of memory locations (i.e., the entire page of memory locations in which the failed memory portion lies). When a page of memory is de-allocated, its memory locations are no longer used to store data, and a computer system's performance may suffer. On the other hand, some operating systems do not respond to memory failures at all. This can also cause a computer system's performance to suffer, and may risk the loss of data.

[0012] To mitigate the above-described situations, in which a computer's operating system de-allocates significantly more memory than has failed (or fails to respond to memory failures at all), the memory controller 102 comprises a memory cache 116 containing spare memory locations 200. The memory controller 102 also comprises logic 118 to, upon receipt of a memory read/write request, 1) direct the read/write request to the memory cache 116 when an address associated with the read/write request resides in the memory cache 116, and 2) direct the read/write request to the second interface 108 when the address associated with the read/write request does not reside in the memory cache 116.

[0013] Upon failure of a portion of a memory module 110, 112 connected to the second interface 108, firmware 120 that is stored and/or executed by any one or more of the memory controller 102, the processor 106, the memory modules 110,112 (for firmware storage only), a management processor 122, or some other device causes one of the spare memory locations of the memory cache 116 to be mapped to the failed portion of the memory module. The firmware 120 may also cause the contents of the failed portion of the memory module 110,112 to be copied into one of the spare memory locations. In this manner, the memory controller 102, in combination with the firmware 120, forms a memory control system that can mitigate (and often prevent) a computer's operating system from de-allocating memory locations that are fully functional.

[0014] In the computer system 100, and by way of example, the firmware 120 is shown to be executed by a management processor 122 coupled to the memory controller 102 via an interface 124.

[0015] An exemplary and more detailed description of the memory cache 116 will now be provided.

[0016] In one embodiment, each of the spare memory locations 200 (FIG. 2) of the memory cache 116 corresponds to a memory “block” (or “line”). However, the spare memory locations could alternately be sized to correspond to various functional units (i.e., portions) of memory 110,112.

[0017] The number of spare memory locations in the memory cache 116 may also vary. However, given that 1) the relative cost of implementing a larger memory cache 116 can be significant, and 2) if a memory module 110, 112 experiences a failure, the failure will usually be a complete failure, or a failure in only a small, localized portion of the memory module 110,112, it will usually be desirable to limit the number of spare memory locations 200 to a relatively small number, such as eight.

[0018] The structure of the memory cache 116 may also vary. However, given that the cache 116 will usually be small, it may often be implemented as a fully associative cache, wherein a physical memory address 202 is stored along with the contents 204 of a portion of memory that corresponds to the address. See, FIG. 2. In addition, entries in the memory cache 116 may store information such as 1) a valid bit, 2) an identifier of a connected memory module 110,112 to which a spare memory location 200 is mapped, or 3) an identifier of a RAM to which a spare memory location 200 is mapped. Valid bits may be used by the logic 118 to determine whether an address associated with a read/write request should be compared to addresses stored in the cache. The identifiers of memory modules or RAMs may be useful in managing how the cache's spare memory locations 200 are used (e.g., upon exhaustion of the memory cache's capacity, as will be described in greater detail later in this description).

[0019] Of note, in a computer system 100 having a plurality of installed memory modules 110, 112, different ones of a memory cache's spare memory locations 200 may be mapped to different ones of the system's memory modules 110, 112.

[0020] An exemplary and more detailed description of the firmware 120 will now be provided.

[0021] In one embodiment, the firmware 120 may monitor error correction activity corresponding to read/write requests that are dispatched via the interface 108. In response to this monitoring, the firmware 120 may then determine whether portions of memory appear to have failed. For example, the firmware 120 may monitor “if” and/or how many times data needs to be error-corrected, and may then determine whether a memory location has failed (or is failing).

[0022] As previously alluded to, there may be times when the capacity of the memory cache 116 becomes exhausted. In such a case, the firmware 120 may allow memory failures to be reported to a computer's operating system. However, in some embodiments, the firmware 120 may be configured to report failures which result in the least number of functional memory locations being de-allocated by a computer's operating system. For example, in one embodiment, the firmware 120 may track the distribution of failed portions of memory modules 110, 112, possibly by storing identifiers of the memory modules 110, 112 and/or RAMs to which the spare memory locations 200 are mapped. Then, upon exhaustion of the memory cache's capacity, the firmware 120 may manage use of the memory cache's spare memory locations 200 by causing a spare memory location 200 that is mapped to 1) a failed portion of a memory module that resides in an area of a memory module having more failures to be remapped to 2) a failed portion of a memory module that resides in an area of a memory module having fewer failures. In this manner, memory failures corresponding to more densely failed portions of memory 110, 112 are more likely to be reported back a computer's operating system—resulting in pages of memory with a greater distribution of memory failures being de-allocated in lieu of pages of memory with a lesser distribution of memory failures being de-allocated.

[0023] In another embodiment, the firmware 120 may track whether spare memory locations 200 are in use as a result of permanent or intermittent errors. Then, upon exhaustion of the memory cache's capacity, the firmware 120 may manage use of the cache's spare memory locations 200 by causing a spare memory location mapped to 1) an intermittently failed portion of a memory module to be remapped to 2) a permanently failed portion of a memory module.

[0024] FIG. 3 illustrates an exemplary method 300 for responding to memory failures using, for example, a device such as the memory controller 102 shown in FIG. 1. The method 300 comprises receiving 302 memory read/write requests at a memory controller, and then, upon failure 304 of a portion of a memory module that is connected to the memory controller, 1) mapping 306 a spare memory location within the memory controller to the failed portion of the memory module, and 2) redirecting 308 ones of the read/write requests directed to the failed portion of the memory module to the spare memory location.