The field of invention pertains generally to the computing sciences; and, more specifically, to a memory controller for multi-level system memory with coherency unit.
Computing systems typically include system memory (or main memory) that contains data and program code of the software code that the system's processor(s) are currently executing. A pertinent bottleneck in many computer systems is the system memory. Here, as is understood in the art, a computing system operates by executing program code stored in system memory. The program code when executed reads and writes data from/to system memory. As such, system memory is heavily utilized with many program codes and data reads as well as many data writes over the course of the computing system's operation. Finding ways to speed-up system memory is therefore a motivation of computing system engineers.
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
One of the ways to speed-up system memory is to have a memory side cache.
According to some embodiments, for example, the near memory 113 exhibits reduced access times by having a faster clock speed than the far memory 114. Here, the near memory 113 may be a faster, volatile system memory technology (e.g., high performance dynamic random access memory (DRAM)). By contrast, far memory 114 may be either a volatile memory technology implemented with a slower clock speed (e.g., a DRAM component that receives a slower clock) or, e.g., a non volatile memory technology that is inherently slower than volatile/DRAM memory.
For example, the lower level 114 may be comprised of an emerging non volatile byte addressable random access memory technology such as, to name a few possibilities, a phase change based memory, a ferro-electric based memory (e.g., FRAM), a magnetic based memory (e.g., MRAM), a spin transfer torque based memory (e.g., STT-RAM), a resistor based memory (e.g., ReRAM) or a “Memristor” based memory. Such emerging non volatile random access memories technologies typically have some combination of the following: 1) higher storage densities than DRAM (e.g., by being constructed in three-dimensional (3D) circuit structures (e.g., a crosspoint 3D circuit structure); 2) lower power consumption densities than DRAM (e.g., because they do not need refreshing); and/or 3) access latency that is slower than DRAM yet still faster than traditional non-volatile memory technologies such as FLASH. The later characteristic in particular permits an emerging non volatile memory technology to be used in a main system memory role rather than a traditional storage role (which is the traditional architectural location of non volatile storage).
Regardless of whether far memory 214 is composed of a volatile or non volatile memory technology, in various embodiments far memory 214 acts as a true system memory in that it supports finer grained data accesses (e.g., cache lines) rather than larger blocked based accesses associated with traditional, deeper non volatile storage (e.g., solid state drive (SSD), hard disk drive (HDD)), and/or, otherwise acts as an (e.g., byte) addressable memory that the program code being executed by processor(s) of the CPU operate out of.
Because near memory 113 acts as a cache, near memory 113 may not have its own individual addressing space. Rather, only far memory 114 includes the individually addressable memory space of the computing system's main memory. In various embodiments near memory 113 truly acts as a cache for far memory 114 rather than acting a last level CPU cache. Generally, a CPU level cache is able to keep cache lines across the entirety of system memory addressing space that is made available to the processing cores 117 that are integrated on a same semiconductor chip as the memory controller 116.
For example, in various embodiments, system memory is implemented with dual in-line memory module (DIMM) cards where a single DIMM card has both DRAM and (e.g., emerging) non volatile memory chips and the DRAM chips effectively act as an on board cache for the non volatile memory chips. Ideally, the more frequently accessed cache lines of any particular DIMM card will be found on that DIMM card's DRAM chips rather than its non volatile memory chips. Given that multiple DIMM cards are typically plugged into a working computing system and each DIMM card is only given a section of the system memory addresses made available to the processing cores 117 of the semiconductor chip that the DIMM cards are coupled to, the DRAM chips are acting as a cache for the non volatile memory that they share a DIMM card with rather than a last level CPU cache.
In other configurations DIMM cards having only DRAM chips may be plugged into a same system memory channel (e.g., a DDR channel) with DIMM cards having only non volatile system memory chips. Ideally, the more frequently used cache lines of the channel will be found in the DRAM DIMM cards rather than the non volatile memory DIMM cards. Thus, again, because there are typically multiple memory channels coupled to a same semiconductor chip having multiple processing cores, the DRAM chips are acting as a cache for the non volatile memory chips that they share a same channel with rather than as a last level CPU cache. Although the above example referred to packaging solutions that included DIMM cards, it is pertinent to note that this is just one example and other embodiments may use other packaging solutions (e.g., stacked chip technology, one or more DRAM and phase change memories integrated on a same semiconductor die or at least within a same package as the processing core(s), etc.).
Referring to the system memory read process of
Here, the placement into near memory of the cache line read from far memory corresponds to placement into cache of a cache line that has most recently been accessed. The placement of the cache line into near memory cache may also correspond to eviction of another cache line from the cache into far memory. That is, the newly accessed cache line may effectively “bump out” another cache line that was in near memory. As just one example, in an embodiment near memory is implemented as a direct mapped cache having multiple “slots” where any cache line supported by the near memory cache can be stored in only one of the slots. In this case, the initial lookup into cache 201 was performed by reading the cache line from the slot that the requested cache line mapped to. Since the cache line read from near memory was not the requested cache line (cache miss), the cache line read from near memory now needs to be put into far memory 205 so that the requested cache line can consume its slot in near memory.
In various embodiments, the cache line being evicted from near memory only needs to be put into far memory if it has a modified state (M). Here, a modified state means the cache line has the most recent data for the cache line. If a cache line having an M state were to be dropped, data consistency problems would result because the most up to date information for the cache line would be lost. Thus, in various embodiments, a cache line that is evicted from near memory is only written back to far memory if it has an M state. Other cache line states (e.g., Exclusive (E), Shared (S) or Invalid (I)) effectively mean there exists a duplicate copy of the cache line in far memory and can therefore be dropped without a data consistency penalty.
Generally, anytime new information is written to a cache line the cache line will assume the M state. Here, the writing of the new information means that the duplicate copy in far memory is “stale” and can no longer be used as its replacement should it be deleted. As such, rather than delete an evicted cache line in the M state it is written back to far memory so that the latest information for the cache line is preserved. In various embodiments a cache line is marked as being in the M state if a reserved “dirty bit” for the cache line is set. Thus, if a cache line that is evicted from near memory has its dirty bit set, the cache line is written back to far memory (the set dirty bit signifying that the cache line has an M state).
If the cache line is not found in near memory (cache miss), the requested cache line is fetched from far memory 213, written over with the new information associated with the write request and then written into near memory 214. Alternatively, a duplicate copy may also be written into far memory so that the copy written into near memory does not have an M state. If no such copy is written into far memory the version written into near memory will have the M state. The same handling of any cache line evicted from near memory as a consequence of writing the newly modified cache line into near memory also transpires 215 (write back of evicted cache line into far memory if it has an M state). Note that in various embodiments the write request granularity may be smaller than the caching granularity. For example, the write may only target one addressable data item in the cache line while the cache line effectively is a grouping of more than one individually addressable data item.
Data hazards can arise in a multi-level system memory as described above. For example, competing requests for a same cache line may be concurrently received (e.g., from different threads) and/or a request for a cache line may be received in a same approximate time frame at which the cache line is transitioning between near memory and far memory.
As will be described in more detail further below, the coherency services unit 302 not only controls the transferal of cache lines between near and far memory (including cache hit/miss status regarding reads into near memory) but is also made aware of incoming memory access requests from requestors (which, e.g., may be queued in a incoming request queue (not shown)). By being made aware of both incoming requests for cache lines and any transferals of cache lines between memory levels, the coherency services unit serves as a centralized location to merge concurrent processes directed to a same cache line.
In the particular situation of
Before discussing additional, more complex processes of
Each of
With each such read request entry the response engine extracts the coherency entry's cache line information to formulate a read response for forwarding to a requestor. Each read request entry holds information that is pertinent to its specific read request such as who the requestor is (e.g., a specific thread and/or processing core). The response engine also refers to this information in order to form a complete response. In one embodiment, a coherence entry's cache line can not be evicted from the internal buffer if it currently has existing read request entries within the internal buffer (as they represent as yet un-serviced read requests) unless and until the existing read requests are serviced.
Some systems may not permit writes to be moved ahead of reads as described above in
As observed in
However in the case of a cache miss, the writing of the cache line that was evicted from the internal buffer into near memory may cause the eviction of another cache line from near memory that now needs to be written back into far memory 215.
In this case, referring to
Referring to
However in the case where the cache line being retrieved is not found in near memory but instead has to be fetched from far memory, recall that according to the process of
For any of the processes of
Notably, the coherency services unit 602 includes a Modified Exclusive Shared Invalid (MESI) state machine 603 that is able to track the formal MESI state of each coherency cache line in the internal buffer 601. Toa larger extent, handling of the M state has already been discussed in the sense that anytime a fresh cache line is called up from system memory, any write activity to the coherency version that resides in the internal buffer will cause the cache line to transition to the M state. Additionally, other requests may arrive that cause other types of MESI state transitions. For example, an explicit request may be received to invalidate the cache line in which case the cache line will transition to the Invalid (I) state, or, multiple read requests may arrive from two different requestors which will transition the cache line to the Shared (S) state consistent with MESI protocol semantics. Additionally, in various embodiments, when a coherency cache line is evicted from the internal buffer 601 it is only written back to system memory if it is currently in the M state. Further still, whenever a process is to take place in which a cache line in the M state that will be written in near memory will also be backed up with a duplicate entry in far memory, the cache line version that is written in near memory may be written as not being in the M state (e.g., by being written in the E state). Likewise, if no such backup is to occur the cache line may be written into near memory as being within the M state.
The coherency services unit 602 also includes a request ordering state machine 605. The request ordering state machine is responsible for implementing the order in which incoming requests are serviced (e.g., moving writes ahead of reads). Here, note that the coherency services unit 602 is coupled to a request queue 603 where received requests are buffered before actually being serviced. The request ordering state machine may snoop the contents of the queue 603 to rearrange the order between requests as they were received by the memory controller vs. the order they are actually serviced.
The coherency services unit 602 also includes a read response state machine 606. As discussed above with respect to
The coherency services unit 602 also includes an eviction state machine 607. The eviction state machine 607 determines which coherence entries within the internal buffer are to be pushed out to system memory in response to, e.g., new requests being received at the memory controller that overwhelm the size of the internal buffer. The eviction state machine 607 may communicate with the read response state machine 606 to ensure that a coherence entry having dependent read entries within the internal buffer 601 is not evicted before the dependent read requests are serviced.
The coherency services unit 602 also includes a lookup state machine to perform reads from near memory and/or far memory and writes to near memory and/or far memory in conjunction with discovering matching coherency entries in the internal buffer in order to effectively implement any of the processes discussed above with respect to
Although not depicted in
An applications processor or multi-core processor 750 may include one or more general purpose processing cores 715 within its CPU 701, one or more graphical processing units 716, a memory management function 717 (e.g., a memory controller) and an I/O control function 718. The general purpose processing cores 715 typically execute the operating system and application software of the computing system. The graphics processing units 716 typically execute graphics intensive functions to, e.g., generate graphics information that is presented on the display 703. The memory control function 717 interfaces with the system memory 702. The system memory 702 may be a multi-level system memory such as the multi-level system memory 212c observed in
Each of the touchscreen display 703, the communication interfaces 704-707, the GPS interface 708, the sensors 709, the camera 710, and the speaker/microphone codec 713, 714 all can be viewed as various forms of I/O (input and/or output) relative to the overall computing system including, where appropriate, an integrated peripheral device as well (e.g., the camera 710). Depending on implementation, various ones of these I/O components may be integrated on the applications processor/multi-core processor 750 or may be located off the die or outside the package of the applications processor/multi-core processor 750.
Embodiments of the invention may include various processes as set forth above. The processes may be embodied in machine-executable instructions. The instructions can be used to cause a general-purpose or special-purpose processor to perform certain processes. Alternatively, these processes may be performed by specific hardware components that contain hardwired logic for performing the processes, or by any combination of programmed computer components and custom hardware components.
Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, FLASH memory, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of media/machine-readable medium suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Number | Name | Date | Kind |
---|---|---|---|
5623628 | Brayton | Apr 1997 | A |
5912839 | Ovshinsky et al. | Jun 1999 | A |
6122715 | Palanca | Sep 2000 | A |
6535958 | Fuoco | Mar 2003 | B1 |
7590918 | Parkinson | Sep 2009 | B2 |
7600078 | Cen et al. | Oct 2009 | B1 |
7756053 | Thomas et al. | Jul 2010 | B2 |
7913147 | Swaminathan et al. | Mar 2011 | B2 |
8051253 | Okin et al. | Nov 2011 | B2 |
8462537 | Karpov et al. | Jun 2013 | B2 |
8462577 | Zeng et al. | Jun 2013 | B2 |
8463948 | Qawami et al. | Jun 2013 | B1 |
8612676 | Dahlen et al. | Jun 2013 | B2 |
8605531 | Kau et al. | Dec 2013 | B2 |
8607089 | Qawami et al. | Dec 2013 | B2 |
8612809 | Casper et al. | Dec 2013 | B2 |
8649212 | Kau et al. | Feb 2014 | B2 |
8838935 | Hinton | Sep 2014 | B2 |
9378133 | Nachimuthu et al. | Jun 2016 | B2 |
9430372 | Nachimuthu et al. | Aug 2016 | B2 |
20030200408 | Mekhiel | Oct 2003 | A1 |
20070005922 | Swaninathan et al. | Jan 2007 | A1 |
20070079070 | Piry | Apr 2007 | A1 |
20070266206 | Kim | Nov 2007 | A1 |
20080016269 | Chow et al. | Jan 2008 | A1 |
20080034148 | Gower | Feb 2008 | A1 |
20080270811 | Chow et al. | Oct 2008 | A1 |
20090313416 | Nation | Dec 2009 | A1 |
20100017556 | Chin | Jan 2010 | A1 |
20100110748 | Best | May 2010 | A1 |
20100131827 | Sokolov | May 2010 | A1 |
20100268884 | Cummings et al. | Oct 2010 | A1 |
20100291867 | Abdulla et al. | Nov 2010 | A1 |
20100293317 | Confalonieri et al. | Nov 2010 | A1 |
20100306446 | Villa et al. | Dec 2010 | A1 |
20100306453 | Doller | Dec 2010 | A1 |
20100318718 | Eilert et al. | Dec 2010 | A1 |
20110153916 | Chinnaswamy et al. | Jun 2011 | A1 |
20110208900 | Schuette et al. | Aug 2011 | A1 |
20110291884 | Oh et al. | Dec 2011 | A1 |
20120254507 | Chang | Oct 2012 | A1 |
20130275661 | Zimmer et al. | Oct 2013 | A1 |
20130275682 | Ramanujan et al. | Oct 2013 | A1 |
20130282967 | Ramanujan | Oct 2013 | A1 |
20130290597 | Faber | Oct 2013 | A1 |
20140040550 | Nale et al. | Feb 2014 | A1 |
20140075107 | Qawami et al. | Mar 2014 | A1 |
20140129767 | Ramanujan et al. | May 2014 | A1 |
20140181403 | Lilly et al. | Jun 2014 | A1 |
20140297938 | Puthiyedath et al. | Oct 2014 | A1 |
20150006805 | Feekes et al. | Jan 2015 | A1 |
20150019824 | Lilly et al. | Jan 2015 | A1 |
20150186275 | Moga et al. | Jul 2015 | A1 |
20150199272 | Goel | Jul 2015 | A1 |
Number | Date | Country |
---|---|---|
2010132655 | Nov 2010 | WO |
Entry |
---|
Lee et al., “Architecting Phase Change Memory as a Scalable DRAM Alternative”, ISCA '09, Jun. 20, 2009, 12 pgs., Austin, Texas, USA. |
Condit et al., “Better I/O Through Byte-Addressable, Persistent Memory”, SOSP '09, Oct. 11, 2009, pp. 133-146. Big Sky, Montana, USA. |
Freitas et al., “Storage-class memory: The next storage system technology”, IBM J. Res. & Dev., Jul./Sep. 2008, pp. 439-447, vol. 52, No. 4/5. |
Akel et al., “Onyx: A Prototype Phase Change Memory Storage Array”,www.flashmemorysummit.com/ . . . /Proceeding_2011/08/11_S301_Akel.pdf, 5 pgs. |
Mearian, “IBM announces computer memory breakthrough Phase-change memory offers 100 times the write performance of NAND flash”, Jun. 30, 2011, 3 pgs. |
Caulfield et al., “Moneta: A High-performance Storage Array Architecture for Next-generation, Non-volatile Memories”, Micro 43: Proceedings of the 43rd Annual IEEE/ACM International Symposium on Microarchitecture, Atlanta, GA Dec. 2010 pp. 385-395. |
“The Non-Volatile Systems Laboratory Coding for non-volatile memories”, http://nvsl.ucsd.edu/ecc, printed Sep. 1, 2011. 2 pgs. |
“The Non-Volatile Systems Laboratory Moneta and Onyx: Very Fast SS”, http://nvsl.ucsd.edu/moneta/, 3 pgs., Sep. 1, 2011. |
“The Non-Volatile Systems Laboratory NV-Heaps: Fast and Safe Persistent Objects”, http://nvsl.ucsd.edu/nvuheaps/, 2 pgs., Sep. 1, 2011. |
“Phase change memory-based ‘moneta’ system points to the future of computer storage”, ScienceBlog, Jun. 2, 2011, 7 pgs. |
Quereshi et al., “Scalable High Performance Main Memory System Using Phase-Change Memory Technology”, ISCA '09, Jun. 20, 2009, 10 pgs., Austin, Texas, USA. |
Kant, Dr. Krishna, “Exploiting NVRAM for Building Multi-Level Memory Systems”, International Workshop on Operating System Technologies for Large Scale NVRAM, Oct. 21, 2008, Jeju, Korea, 19 pages. |
Bailey et al., “Operating System Implications of Fast, Cheap, Non-Volatile Memory” 13th USENIX, HOTOS11 2011, May 9-11, 2011, 5 pgs. |
Raoux et al., “Phase-change random access memory: A scalable technology”, IBM J. Res. & Dev., Jul./ Sep. 2008, pp. 465-479, vol. 52, No. 4/5. |
Chen et al., “Rethinking Database Algorithms for Phase Change Memory”, 5th Biennial Conference on Innovative Data Systems Research (CIDR '11), Jan. 9, 2011, 11 pgs., Asilomar, California, USA. |
Jacob et al., “The Memory System You Can't Avoid It, You Can't Ignore It, You Can't Fake It”, 2009, 77 pgs., Morgan & Claypool. |
Mogul et al., “Operating System Support for NVM+DRAM Hybrid Main Memory”, 12th Workshop on Hot Topics in Operating Systems (HatOS XII), May 18, 2009, 9 pgs. |
International Search Report and Written Opinion from co-pending PCT/US2016/018488, dated May 31, 2016, 11 pages total. |
Wu, et al., “eNVy: A Non-Volatile, Main Memory Storage System” 1994 ACM., ASPLOS VI. pp. 86-97. |
Dhiman, et al. “PDRAM: A Hybrid PRAM and DRAM Main Memory System”, Jul. 26, 2009, Department of Computer Science and Engineering, 6 pages. |
Number | Date | Country | |
---|---|---|---|
20160283389 A1 | Sep 2016 | US |