WO2016114789A1

WO2016114789A1 - Memory manager

Info

Publication number: WO2016114789A1
Application number: PCT/US2015/011690
Authority: WO
Inventors: Reza BACCHUS
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-01-16
Filing date: 2015-01-16
Publication date: 2016-07-21

Abstract

An example implementation relates to collecting status information about memory modules of a computing system. The memory modules of the computing system can include a volatile memory module and a non-volatile memory module. A user interface can display the status information and can receive user input for management of the memory modules.

Description

MEMORY MANAGER BACKGROUND

[0001 ] Computing systems can implement volatile memory as system memory. Computing systems also can implement non-volatile memory as system memory. Volatile memory and non-volatile memory may support different memory features or may implement similar memory features differently. Different utilities may be used to manage volatile memory and non-volatile memory respectively.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples will be described below with reference to the following figures.

[0003] FIG. 1 is a block diagram illustrating an example computing system according to some implementations.

[0004] FIG. 2 is a block diagram illustrating an example computing system according to other implementations.

[0005] FIG. 3 is a block diagram illustrating an example memory manager that includes a machine-readable medium encoded with instructions to manage memory modules according to some implementations.

[0006] FIG. 4 is a block diagram illustrating an example memory manager that includes a machine-readable medium encoded with instructions to manage memory modules according to other implementations.

[0007] FIG. 5 is a flow diagram of a method for managing memory modules according to some implementations.

[0008] FIG. 6 is a flow diagram of a method for managing memory modules according to other implementations.

[0009] FIG. 7 is a flow diagram of a method for managing memory modules according to other implementations. DETAILED DESCRIPTION

[0010] Computing systems can implement volatile memory, such as dynamic random-access memory (DRAM), as system memory. Implementation of volatile memory can be facilitated by various management functions including

identification, training, initialization, error detection and reporting, and pre-failure warranty notification.

[001 1 ] Alternatively or additionally, non-volatile memory technologies can be implemented in computing systems. Examples of non-volatile memory include flash memory, phase-change memory, spin-transfer torque memory, resistive random-access memory (also referred to as memristor memory), programmable metallization cell, carbon nanotube memory, magnetoresistive random-access memory, ferroelectric random-access memory, and the like. Non-volatile memory can utilize the aforementioned management functions associated with volatile memory. Additionally, non-volatile memory may employ additional features, such as data persistence, data encryption, fast booting, a variety of addressing modes (e.g., volatile addressing, persistent addressing and block storage addressing), and data migration. For example, non-volatile dual in-line memory modules (NVDIMMs), which combine volatile DRAM, non-volatile flash memory, and a power source (e.g., a supercapacitor, a battery, or the like), can transfer the data contents of its volatile DRAM to its persistent non-volatile flash memory in the event of a system crash or power failure. Some of the foregoing additional features may also be employed by volatile memory, although the implementation, capabilities, and performance of those features on volatile memory may differ in comparison to similar features employed by non-volatile memory.

[0012] Management functions for volatile memory and non-volatile memory are deployed in separate utilities at varying levels of a computing system, such as in the BIOS (basic input/output system) firmware, in operating system drivers, in system management software and firmware, and in applications. The separate utilities may differ from each other with respect to user interfaces, ease of use, deployment, and version control, among other aspects. A user may need to learn and operate multiple processes and/or programs in order to effectively manage a computing system having both non-volatile memory and volatile memory. Thus, a user experience of the computing system may be degraded by inefficiencies and difficulties arising from having disparate utilities for managing the volatile and non-volatile memory.

[0013] Referring now to the figures, FIG. 1 is a block diagram of an example computing system 100 that includes memory modules 102, a memory manager 1 10 for the management of the memory modules 102, and a user interface 108. In some example implementations, the computing system 100 can be a laptop computer, a desktop computer, a workstation, a server, a mobile phone, a tablet computing device, or other electronic device. The memory modules 102 include a non-volatile memory module 104 and a volatile memory module 106 (that is, the non-volatile memory module 104 and the volatile memory module 106 can be referred to collectively as the memory modules 102). In some implementations, the non-volatile memory module 104 can include at least one memory module (also known as a memory device or a memory package) having a non-volatile memory type, such as, for example, a flash memory, a phase-change memory, a spin-transfer torque memory, a resistive random-access memory (memristor memory), and the like. In some implementations, the volatile memory module 106 can include at least one memory module having a volatile memory type, such as, for example, DRAM, static random-access memory (SRAM), and the like. As but one example, the memory modules 102 may be NVDIMMs that include a flash memory as the non-volatile memory 104 and DRAM as the volatile memory module 106. It should be understood that the non-volatile memory module 104 and the volatile memory module 106 can represent multiple non-volatile memory modules and volatile memory modules, respectively.

[0014] In some implementations, individual ones of the memory modules 102 can each include an on-board controller that performs operations on data stored on the memory modules 102. For example, an operation of the controller can be to detect the occurrence and location of errors on the memory modules 102. Another example operation of the controller can be to encrypt data stored to the memory modules 102 and to decrypt data requested/retrieved from the memory modules 102. In some implementations, additional examples of controller operations can belong to a class of data acceleration operations, whereby the controller performs a function on data stored on the memory modules 102 without utilizing a processor of the computing system 100 (e.g., a central processing unit). By virtue of not utilizing a processor of the computer system 100, the operation can be performed locally on the memory modules 102 and in less time than if the processor was utilized (in this manner, the aforementioned

encryption/decryption operation may also be deemed a data acceleration operation). For example, the class of data acceleration operations can include a search operation to search the memory modules 102 for data with specific contents or attributes (e.g., based on a user-inputted search request), a data manipulation operation that performs mathematical or transformative operations on data stored on the memory modules 102 (e.g., based on user input that includes a size and memory location of the operands, a size and memory location of the results, and an operation to perform), an initialization operation that initializes at least a portion of the memory modules 102 with pre-defined data patterns (e.g., the data patterns may be pre-defined by user input), and a test operation that tests the data integrity of the memory modules 102.

[0015] The user interface 108 can receive, from a user of the computing system 100, a user input related to management of the memory modules 102. For example, the user interface 108 can include a keyboard, a pointing device (e.g., a mouse, a trackball, a stylus, and the like), a microphone, a touchscreen, a camera, and/or the like, for receiving the user input. The user interface 108 can be communicatively coupled to the memory manager 1 10, and the user input can be transmitted from the user interface 108 to the memory manager 1 10.

[0016] The user interface 108 also can display a status information about the memory modules 102 collected by the memory manager 1 10, as will be described further herein below. For example, the user interface 108 can include (or can be coupled to) a display device, such as a monitor, a screen, a

touchscreen, or the like. In some implementations, the user interface 108 can also display options and/or parameters related to the management of the memory modules 102 by the memory manager 1 10 described below, and the user input received at the user interface 108 can relate to or be a selection from the displayed options and/or parameters. [0017] The memory manager 1 10 can be communicatively coupled to the memory modules 102 (more particularly, to the non-volatile memory module 104 and to the volatile memory module 106). The memory manager 1 10 can manage (or, in other words, administrate) the memory modules 102 by virtue of

management modules 1 12, 1 14, 1 16, 1 18, and 120, as will be described further herein below. In some implementations, the memory manager 1 10 can manage the memory modules 102 based on user input received by the user interface 108. The memory manager 1 10 (and more particularly, the management modules 1 12, 1 14, 1 16, 1 18, and 120) can include a set of instructions encoded on a machine- readable medium and executable by a processor. Additionally or alternatively, the memory manager 1 10 (and, the management modules 1 12, 1 14, 1 16, 1 18, and 120) can include hardware device(s) comprising electronic circuitry for implementing the functionality described below. The management modules 1 12, 1 14, 1 16, 1 18, and 120 included in the memory manager 1 10 will now be described in turn.

[0018] In some implementations, the memory manager 1 10 can collect (or in other implementations, poll, request, or receive) status information about the memory modules 102, by virtue of a management module 1 12. In some implementations, the status information can be displayed on the user interface 108, as discussed above. In some implementations, the memory manager 1 10 can automatically collect the status information of the memory modules 102, and more particularly, the memory manager 1 10 can automatically collect the status information at regular periods, such as at approximately five minute intervals or greater (e.g., up to a period that can be useful for monitoring and maintaining the memory modules, such as once daily, although longer period durations may correlate with a decrease in usefulness of the collected status information for detecting memory module failures and any subsequent user intervention).

[0019] For example, the status information can include an operating mode information that describes how the memory modules 102 or portions thereof are configured to operate in operating modes such as an addressing mode (e.g., a persistent mode, a volatile mode, a block storage mode, and the like), an encryption mode, a data acceleration mode, and/or a fast boot mode. The status information also can include a temperature information about the memory modules 102, for example, from a temperature sensor of the memory modules 102. The status information also can include a memory map (that is, the layout of the memory modules 102), which can include, among other things, usage types within the memory modules 102, the amount and location of free memory in the memory modules 102, and the location of errors in the memory modules 102. The status information also can include a condition information about an equipment associated with the memory modules 102, such as a health and life estimation of a supercapacitor of an NVDIMM serving as the memory module 102.

[0020] The status information also can include, for example, an error report about the memory modules 102. For example, with respect to non-volatile memory module 104, errors on the non-volatile memory module 104 can be announced by toggling an EVENT signal (e.g., by toggling the EVENT signal for identifying a temperature condition from high to low to high within a

predetermined time period). In response to the toggled EVENT signal, a controller can poll error registers of the non-volatile memory module 104 to determine the nature and address of the error and log the determined error information to a maintenance log. With respect to the volatile memory module 106, BIOS can periodically (e.g., at approximately five minute intervals) accumulate errors detected by an on-board controller of the volatile memory module 106 (e.g., errors can be accumulated categorically, such as by DIMM identifier, rank, bank, row, and column) and periodically (e.g., at approximately every twenty-four hours) identify row and column failures of the volatile memory module 106 based on the accumulated errors. BIOS can log, to a maintenance log (which can be the same as or separate from the maintenance log for reporting errors of the non-volatile memory module 104), row and column failures that exceed a threshold (which may indicate that the DIMM should be replaced).

Accordingly, the memory manager 1 10 can collect the maintenance log(s) described above to acquire, as status information, error report(s) about the nonvolatile memory module 104 and the volatile memory module 106. It should be understood that other techniques of logging errors of the memory modules 102 can be used to generate a maintenance log that is collected by the memory manager 1 10.

[0021 ] In some implementations, the memory manager 1 10 can set up (or, in other words, configure) at least one of the memory modules 102 to operate in at least one of a plurality of operating modes, by way of a management module 1 14. The various operating modes can include, for example, an addressing mode, an encryption mode, a data acceleration mode, and/or a fast boot mode.

[0022] For example, the memory manager 1 10 can set up the memory modules 102 into a particular addressing mode, including without limitation, a persistent mode, a volatile mode, a block storage mode, and the like. The memory manager 1 10 also can set up the memory modules 102 into an encryption mode, which causes data stored on the memory modules 102 to become encrypted (e.g., by instructing a controller of the memory modules 102 to encrypt and decrypt data of the memory modules 102, as described above). The memory manager 1 10 can also set up the memory modules 102 into a data acceleration mode, which can enable and instruct the memory modules 102 to perform a data acceleration operation, such as a search operation, a data manipulation operation, an initialization operation, or an test operation, as described above (any user input required for the data acceleration operation can be provided via user interface 108). The memory manager 1 10 also can set up the memory modules 102 into a fast boot mode (also known as an "instant-on" mode), which can, for example, bypass an initialization of the memory modules 102 during a system boot sequence and/or save a persistent system state in the memory modules 102 to be restored upon a system boot sequence.

[0023] In some implementations, the memory manager 1 10 can set up the memory modules 102 into more than one of the operating modes simultaneously. For example, a non-volatile memory module 104 may be set up to operate in a persistent addressing mode and also in an encryption mode, by virtue of which the data stored in the persistent addressing mode may be more secure against malicious attacks. In some implementations, the memory manager 1 10 can set up a portion (a subset) of the memory modules 102 into an operating mode. In some implementations, the memory manager 1 10 can set up a particular one of the memory modules 102 into a plurality of operating modes (e.g., a first portion of a non-volatile memory module may be set up into a persistent addressing mode and a second portion of the same non-volatile memory module may be set up into a volatile addressing mode). In some implementations, an operating mode can be selected from among the volatile mode, the persistent mode, the block storage mode, the encryption mode, the data acceleration mode, and the fast boot mode, by user input received at the user interface 108, and the memory manager 1 10 can set up the memory modules 102 in accordance with the operating mode selected by the user input. In some implementations, the management module 1 14 can be aware that some of the foregoing operating modes may not be available to particular ones of the memory modules 102, depending on whether the particular ones of the memory modules 102 are a nonvolatile memory module 104 or a volatile memory module 106. For example, a volatile memory module 106 may not be capable of operating in a persistent addressing mode by virtue of volatile memory requiring power to maintain information stored thereon. Moreover, if user input received at the user interface 108 selects an operating mode that is not available for particular ones of the memory modules 102, the memory manager 1 10 can, in some implementations, inform the user that the selection is invalid via user interface 108.

[0024] In some implementations, the memory manager 1 10 can load machine executable instructions that control operation of the memory modules 102, by virtue of a management module 1 16. For example, the machine executable instructions may be an operating system device driver, an application

programming interface (API), a firmware that can be loaded into a controller of the memory modules 102, and the like. In some implementations, the machine executable instructions can be selected by the user input received at the user interface 108.

[0025] In some implementations, the memory manager 1 10 can migrate data between different ones of the memory modules 102, by virtue of a management module 1 18. In some implementations, the memory manager 1 10 can migrate data from the non-volatile memory module 104 to the volatile memory module 106, from a first one of the non-volatile memory module 104 to a second one of the non-volatile memory module 104, from the volatile memory 106 to the nonvolatile memory 104, or from a first one of the volatile memory 106 to a second one of the volatile memory 106. In some implementations, the memory manager 1 10 can migrate the data based on user input received at the user interface 108, where the user input can include information identifying, for example, the data to migrate, on which of the memory modules 102 the data to migrate is initially located, and to which of the memory modules 102 the data is to be migrated. In some implementations, the user input can be based on a memory map (e.g., provided by the management module 1 12) displayed on the user interface 108. By virtue of the memory manager 1 10 being able to migrate data between different ones of the memory modules 102, data can be moved from a memory module that is failing or has failed, to an operational memory module, thus potentially avoiding data loss.

[0026] In some implementations, the memory manager 1 10 can migrate data between different operating modes of the memory modules 102, by virtue of a management module 120. As described above, operating modes of the memory modules 102 can include an addressing mode (e.g., a persistent mode, a volatile mode, a block storage mode, and the like), an encryption mode, a data

acceleration mode, and/or a fast boot mode. The different operating modes can be, for example, on the same one of the memory modules 102 or on different ones of the memory modules 102. In some implementations, the memory manager 1 10 can migrate the data based on user input received at the user interface 108, where the user input can include information identifying, for example, the data to migrate (including where the data is initially located when the user input is received) and to what operating mode the data is to be migrated. In some implementations, the user input can be based on a memory map (e.g., as provided by the management module 1 12) displayed on the user interface 108. As an illustrative example, a user input may indicate that data is to be moved to a persistent mode, and the memory manager 1 10 can identify an unused persistent mode memory space and migrate the data to that identified unused persistent mode memory space. [0027] FIG. 2 is a block diagram of an example computing system 200. The computing system 200 can include memory modules 202, a user interface 208, and a memory manager 210, which can be analogous in many respects to the memory modules 102, the user interface 108, and the memory manager 1 10, respectively. As with the memory modules 102, the memory modules 202 can include a non-volatile memory module 204 and a volatile memory module 206, which can be analogous to the non-volatile memory module 104 and the volatile memory module 106, respectively. As with the memory manager 1 10, the memory manager 210 can manage the memory modules 202, by incorporating, for example, any of the management modules 1 12, 1 14, 1 16, 1 18, and 120 described above with respect to the memory manager 1 10.

[0028] In some implementations, the user interface 208 and the memory manager 210 reside on separate devices. For example, the user interface 208 can reside on a first device, such as a remote computer 214, and the memory manager 210 can reside on a second device separate from the first device, such as a computer 201 . In some implementations, the computer 201 and the remote computer 214 may each include any kind of wired or wireless network interface, such that the memory manager 210 and the user interface 208, residing respectively on the computer 201 and the remote computer 214, can

communicate by way of a network 216. In some example implementations, the computer 201 can be a laptop computer, a desktop computer, a workstation, a server, a mobile phone, a tablet computing device, or other electronic device. Similarly, in some example implementations, the remote computer 214 can be a laptop computer, a desktop computer, a workstation, a server, a mobile phone, a tablet computing device, or other electronic device.

[0029] In some implementations, the memory manager 210 can be included in a remote management controller 212 of the computer 201 . In some

implementations, the remote management controller 212 can be a lights out management controller or the like, and can include any kind of wired or wireless network interface to provide an out-of-band network transmission path between the memory manager 210 and the user interface 208 of the remote computer 214 via network 216. In some implementations, the user interface 208 can communicate with the remote management controller 212 (and more particularly, the memory manager 210) via the out-of-band network transmission path such that a user can remotely manage aspects of the computer 201 (including the memory modules 202) in the event of a failure of the computer 201 (or a failure of the computing system 200) or even when the computer 201 has been powered off.

[0030] As with the user interface 108, the user interface 208 can receive a user input for the management of the memory modules 202, and the

management of the memory modules 202 by the memory manager 210 can be based on the user input. The user input can be transmitted from the user interface 208 to the memory manager 210 by way of a network transmission (e.g., such as an out-of-band network transmission) over the network 216.

[0031 ] The user interface 208 also can display a status information about the memory modules 202 collected by the memory manager 210 (more particularly, by a management module 1 12 included in the memory manager 210), among other information provided by the memory manager 210. The status information can be transmitted from the memory manager 210 to the user interface 208 by way of a network transmission (e.g., such as an out-of-band network

transmission) over the network 216, and the user interface 208 can display the status information of the memory modules 202 transmitted from the memory manager 210.

[0032] In some implementations, the memory manager 210 can predict failures of the memory modules 202 and notify the user of predicted failures, in a manner similar to that described further herein below with respect to FIG. 3 and FIG. 7.

[0033] FIG. 3 is a block diagram illustrating a memory manager 300 that includes a machine-readable medium encoded with instructions to manage memory modules according to an example implementation. In some example implementations, the memory manager 300 can form part of a laptop computer, a desktop computer, a workstation, a server, a mobile phone, a tablet computing device, and/or other electronic device. The memory manager 300 can be communicatively coupled to memory modules including a non-volatile memory module and a volatile memory module. The memory manager 300 can include a processor 302 coupled to a machine-readable medium 303. In some

implementations, the memory manager 300 can be communicatively coupled with a user interface 304. The user interface 304 can include a display device, such as a screen, a monitor, a touchscreen, or the like. The user interface 304 also can include an input device, such as a keyboard, a pointing device (e.g., a mouse, a trackball, a stylus, and the like), a camera, a microphone, and/or the like.

[0034] The processor 302 can include a central processing unit, a multiple processing unit, a microprocessor, an application-specific integrated circuit, a field programmable gate array, and/or other hardware device suitable for retrieval and/or execution of instructions from the machine-readable medium 303 (e.g., instructions 306, 307, 308, 310, and 312) to perform the various functions discussed herein. Additionally or alternatively, the processor 302 can include electronic circuitry for performing the functionality of instructions 306, 307, 308, 310 and/or 312.

[0035] The machine-readable medium 303 can be any medium suitable for storing executable instructions, such as random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk drives, optical discs, and the like. In some example implementations, the machine-readable medium 303 can be a non-transitory medium, where the term "non-transitory" does not encompass transitory propagating signals. As described further herein below, the machine-readable medium 303 can be encoded with a set of executable instructions 306, 307, 308, 310, and 312.

[0036] Instructions 306 can collect status information about memory modules of a computing system, the memory modules including a volatile memory module and a non-volatile memory module. In some implementations, the instructions 306 can collect the status information automatically and/or periodically, for example, at a period that can be useful for monitoring the memory modules and for mitigating memory errors reported in the status information (e.g., at

approximately five minute intervals, or up to twenty-four hour intervals). In some implementations, the status information can include an error report about the mennory modules (which can be similar in many respects to the memory report described above with respect to management module 1 12 of FIG. 1 ). In some implementations, status information can include at least one of: an operating mode information that describes the operating configuration of the memory modules (e.g., whether the memory modules are operating in a particular addressing mode, an encryption mode, a data acceleration mode, and/or a fast boot mode), a temperature information about the memory modules, a memory map of the memory modules, a condition information about an equipment associated with the memory modules, or a version identifier of machine executable instructions that control operation of the memory modules.

[0037] Instructions 307 can evaluate status information (such as the status information collected by instructions 306) to predict a failure of the memory modules and generate a failure prediction report. For example, to predict a failure of the memory modules, instructions 307 can, at a pre-defined time (e.g., at regular 24-hour periods), retrieve the error report collected as status

information by instructions 306 and analyze for patterns in the addresses of reported errors (e.g., row and column addresses of a volatile DIMM). If the number of unique addresses of reported errors on a particular one of the memory modules exceeds a pre-defined threshold, then the instructions 307 deem the probability increased of an uncorrectable error occurring on the particular one of the memory modules and generates a failure prediction report that indicates the particular one of the memory modules is predicted to fail and should be replaced. If, on the other hand, the reported errors are substantially from the same address on a particular one of the memory modules, then the instructions 307 deem the probability of occurrence of an uncorrectable error to be low and generates a failure prediction report indicating that no memory modules are predicted to fail, that the memory modules are functioning properly, and/or that the memory modules do not require replacement.

[0038] Instructions 308 can transmit status information, such as the status information collected by instructions 306, and/or a failure prediction report, such as the failure prediction report generated by instructions 307, from the memory manager 300 to the user interface 304 via a network transmission, such as the out-of-band network transmission path described above with reference to FIG. 2.

[0039] Instructions 310 can control the user interface 304 to display status information, such as the status information collected by instructions 306 and transmitted by instructions 308. Instructions 310 also can control the user interface 304 to display the failure prediction report transmitted by instructions 308.

[0040] Instructions 312 can receive, from the user interface 304, a user input for the management of the memory modules coupled to the memory manager 300. In some implementations, instructions 304 can receive the user input from the user interface 304 via an out-of-band network transmission path, such as the out-of-band network transmission path described above with reference to FIG. 2. For example, the user input can be a user selected option and/or parameter used by the memory manager 300 in executing a memory module management instruction, which may include, without limitation, an instruction to set up memory modules to operate in operating modes selected by the user input (e.g., as described below with respect to instructions 406), an instruction to migrate data between different ones of the memory modules based on the user input (e.g., as described below with respect to instructions 410), or an instruction to migrate data between different operating modes of the memory modules based on the user input (e.g., as described below with respect to instructions 412).

[0041 ] FIG. 4 is a block diagram illustrating a memory manager 400 that includes a machine-readable medium encoded with instructions to manage memory modules according to another example implementation. In some example implementations, the memory manager 400 can form part of a laptop computer, a desktop computer, a workstation, a server, a mobile phone, a tablet computing device, and/or other electronic device. The memory manager 400 can be communicatively coupled to memory modules including a non-volatile memory module and a volatile memory module. The memory manage 400 can include a processor 402 coupled to a machine-readable medium 403, and the processor 402 and the machine-readable medium 403 can be analogous in many respects to the processor 302 and the machine-readable medium 303, respectively. In some implementations, the memory manager 400 can be communicatively coupled with a user interface 404, which can be analogous to the user interface 304 in many respects. As with the user interface 304, the user interface 404 can include a display device (e.g., a screen, a monitor, a touchscreen, and the like) and an input device (e.g., a keyboard, a pointing device, a camera, and/or a microphone). In some implementations, the user interface 404 can display options and/or parameters on a graphical user interface of the user interface 404, such that a user can provide user input selected from among (or based on) the displayed options and/or parameters for the management of the memory modules.

[0042] The machine-readable medium 403 can be encoded with a set of instructions 405, 406, 408, 410, and 412 that can be retrieved and executable by the processor 402. Additionally or alternatively, the processor 402 can include electronic circuitry for performing the functionality of instructions 405, 406, 408, 410, and/or 412.

[0043] Instructions 405 can receive, from the user interface 404, a user input for the management of the memory modules coupled to the memory manager 400. Instructions 405 can be analogous to instructions 312 in many respects.

[0044] Instructions 406 can set up the memory modules to operate in at least one of a plurality of operating modes, based on user input. In some

implementations, instructions 406 can receive, from user interface 404, user input that calls for at least a portion of the memory modules to be set up into an operating mode, such as a particular addressing mode (e.g., a volatile mode, a persistent mode, a block storage mode, and the like), an encryption mode, a data acceleration mode, and/or a fast boot mode, and instructions 406 can set up the memory modules to operate in the operating mode in accordance with the user input.

[0045] Instructions 408 can load machine executable instructions that control operation of the memory modules, based on user input. In some

implementations, instructions 408 can receive, from user interface 404, user input that selects the machine executable instructions (e.g., an operating system device driver, an API, a firmware, or the like) to be loaded, and the instructions 408 can load the machine executable instructions selected by the user input. In some implementations, the user input can direct the instructions 408 to

automatically update the machine executable instructions that control operation of the memory modules to a newer version (for example, by checking with an update server of the manufacturer of the memory modules).

[0046] Instructions 410 can migrate data between different ones of the memory modules, based on user input. In some implementations, instructions 410 can receive, from user interface 404, user input that indicates what data to migrate, on which of the memory modules the data to migrate is initially located (a "source memory module"), and to which of the memory modules the data is to be migrated (a "destination memory module"). In accordance with the user input, instructions 410 can migrate the data from the source memory module to the destination memory module.

[0047] Instructions 412 can migrate data between different operating modes of the memory modules, based on user input. In some implementations,

instructions 412 can receive, from user interface 404, user input that indicates what data to migrate (including where the data is located when the user input is received, i.e., a "source operating mode") and to what operating mode the data is to be migrated (a "destination operating mode"). In accordance with the user input, instructions 412 can migrate the data from the source operating mode to the destination operating mode.

[0048] In some implementations, the machine-readable medium 403 can also be encoded with instructions to identify, train, and initialize the memory modules and to issue a pre-failure warranty notification.

[0049] FIG. 5 is a flow diagram of a method 500 for managing memory modules. The method 500 can be implemented in the form of executable instructions stored on a machine-readable medium and/or in the form of electronic circuitry. Although execution of the method 500 is described below with reference to memory manager 300, it should be understood that method 500 can be performed by any other suitable electronic circuitry, such as, for example, the memory manager 1 10 of FIG. 1 , the memory manager 210 of FIG. 2, or the memory manager 400 of FIG. 4. As described above, the memory manager 300 can be communicatively coupled to memory modules of a computing system, the memory modules including a non-volatile memory module and a volatile memory module. In some implementations, one or more steps of method 500 can be executed substantially concurrently or in a different order than shown in FIG. 5. In some implementations, method 500 can include more or less steps than are shown in FIG. 5. In some implementations, one or more of the steps of method 500 may, at certain times, be ongoing and/or may repeat.

[0050] The method 500 starts, and at block 502, the memory manager 300 can collect status information about the memory modules of a computing system, where the memory modules include a volatile memory module and a non-volatile memory module. In some implementations, block 502 can collect the status information in an ongoing, periodic manner, for example, at a period that can be useful for monitoring the memory modules and for mitigating memory errors reported in the status information (e.g., at approximately five minute intervals, or up to twenty-four hour intervals). In some implementations, the status

information includes an error report regarding the memory modules (which can be similar in many respects to the memory report described above with respect to the management module 1 12 of FIG. 1 ). In some implementations, the status information can include at least one of: an operating mode information that describes an operating mode of the memory modules (e.g., whether the memory modules are operating in a particular addressing mode, an encryption mode, a data acceleration mode, and/or a fast boot mode), a temperature information about the memory modules, a memory map of the memory modules, a condition information about an equipment associated with the memory modules, or a version identifier of machine executable instructions that control operation of the memory modules.

[0051 ] At block 504, the memory manager 300 transmits the status

information collected at block 502 from the memory manager 300 to a user interface (e.g., user interface 304) via a network transmission. For example, in some implementations, the memory manager 300 and the user interface may reside on separate electronic devices, and the memory manager 300 can include any wired or wireless network interface for establishing an in-band or an out-of- band network transmission path with the user interface via a network, as described above with reference to FIG. 2. In some implementations, the memory manager 300 transmits the status information via an out-of-band network transmission.

[0052] At block 506, the memory manager 300 can control the user interface to display the status information. In some implementations, the status

information displayed at block 506 can be the status information collected at block 502 and transmitted to the user interface at block 504.

[0053] At block 508, the memory manager 300 receives user input from the user interface for management of the memory modules. In some

implementations, the user input can be a selection of a memory module management process to be performed, such as, without limitation, a process to set up at least one of the memory modules communicatively coupled to the memory manager 300 to operate in an operating mode (as described below with respect to block 606), a process to migrate data from a first memory module of the memory modules to a second memory module of the memory modules (as described below with respect to block 608), a process to migrate data from a first operating mode of the memory modules to a second operating mode of the memory modules (as described below with respect to block 610), or a process to update to a newer version of machine executable instructions that control operation of the memory modules (as described below with respect to block 612). In some implementations, the user input can relate to options and/or parameters for performing one or more of the aforementioned memory management processes, as will be described further herein below.

[0054] In some implementations, the user input may be provided by a user in response to or based on the status information displayed at block 506. As but one illustration, a user may determine from the status information (e.g., the error report) that a memory module is failing and may subsequently send a

preventative or corrective user input to the memory manager 300. For example, the memory manager 300 can receive a user input from the user, via the user interface, directing the memory manager 300 to migrate data from the failing mennory module to a non-failing operational memory module. After block 508, the method 500 can end.

[0055] FIG. 6 is a flow diagram of a method 600 for managing memory modules. The method 600 can be implemented in the form of executable instructions stored on a machine-readable medium and/or in the form of electronic circuitry. Although execution of the method 600 is described below with reference to memory manager 400, it should be understood that method 600 can be performed by any other suitable electronic circuitry, such as, for example, the memory manager 1 10 of FIG. 1 , the memory manager 210 of FIG. 2, or the memory manager 300 of FIG. 3. As described above, the memory manager 400 can be communicatively coupled to memory modules of a computing system, the memory modules including a non-volatile memory module and a volatile memory module.

[0056] In some implementations, one or more steps of method 600 can be executed substantially concurrently or in a different order than shown in FIG. 6. In some implementations, method 600 can include more or less steps than are shown in FIG. 6. In some implementations, one or more of the steps of method 600 may, at certain times, be ongoing and/or may repeat. Some blocks of method 600 may be performed in parallel with and/or after method 500 of FIG. 5 and/or method 700 of FIG. 7 described below.

[0057] The method 600 starts, and at block 602, the memory manager 400 receives, from a user interface (e.g., user interface 404), user input for the management of the memory modules of the computing system. Block 602 can be analogous in many respects to block 508. As with the user input described above with respect to block 508, the user input received at block 602 can be a selection of a memory module management process to be performed, such as any of the management processes described below at blocks 606, 608, 610, and 612. In some implementations, the user input can relate to options and/or parameters for performing blocks 606, 608, 610, and 612.

[0058] At block 604, the memory manager 400 determines the memory module management process to execute (e.g., from among the blocks 606, 608, 610, and 612), based on user input received at block 602. In some implennentations, the memory manager 400 can determine that, based on the user input received at block 602, multiple ones of the memory management routines are to be executed, whether sequentially or in parallel. After block 604, control passes to block 606, 608, 610, and/or 612 accordingly.

[0059] At block 606, the memory manager 400 can set up at least one of the memory modules (or at least a portion of at least one of the memory modules) to operate in at least one of a plurality of operating modes, based on user input received at block 602. For example, at block 602, the memory manager 400 may receive, user input from the user interface directing the memory manager 400 to set up at least one of the memory modules to operate in an operating mode selected from among an addressing mode (e.g., a volatile mode, a persistent mode, a block storage mode, and the like), an encryption mode, a data acceleration mode, and/or a fast boot mode. In response, the memory manager 400 can set up the memory modules in accordance with the user input.

Additionally, the user input involved at block 606 can include user selected options/parameters, such as an identification of the memory module to set up and what to operating mode the identified memory module is to be set up.

[0060] At block 608, the memory manager 400 can migrate data between different ones of the memory modules, based on user input received at block 602. For example, at block 602, the memory manager 400 may receive user input from the user interface directing the memory manager 400 to migrate data between a first memory module of the memory modules and a second memory module of the memory modules, and the memory manager 400 migrates the data between the first memory module and the second memory module based on the user input. In some implementations, the user input involved at block 608 can include user selected options/parameters, such as identification of the data to migrate, the first memory module and the second memory module. In some implementations, the first memory module can be a volatile memory module, and the second memory module can be a non-volatile memory module.

[0061 ] At block 610, the memory manager 400 can migrate data between different operating modes of the memory modules, based on user input received at block 602. For example, at block 602, the memory manager 400 may receive user input from the user interface directing the memory manager 400 to migrate data from a first operating mode of the memory modules (e.g., the operating mode where the data initially resides when the user input is received) to a second operating mode of the memory modules, and in response, the memory manager 400 migrates the data from the first operating mode to the second operating mode based on the user input. In some implementations, the memory manager 400 can identify an available memory space (i.e., an unallocated or unused memory space) that is set up to operate in the second operating mode, and migrate the data to the identified available memory space. In some

implementations, the user input involved at block 610 may include user selected options/parameters, such as identification of the data to migrate, the first operating mode, and/or the second operating mode. Each of the first and second operating modes can include, for example, an addressing mode (e.g., a persistent mode, a volatile mode, or a block storage mode), an encryption mode, a data acceleration mode, or a fast boot mode. In some cases, the first and second operating modes can be on the same one of the memory modules, and in other cases, the first and second operating modes can be on different ones of the memory modules.

[0062] At block 612, the memory manager 400 can update machine

executable instructions that control operating of the memory modules to a newer version. The memory manager 400 can perform block 612 by first identifying if a newer version of the machine executable instructions is available (e.g., by checking with an update server of the manufacturer of the memory modules). If a newer version of the machine executable instructions is available, the memory manager 400 can acquire the newer version of the machine executable

instructions and load the newer version of the machine executable instructions to, for example, a memory, a processor, or a controller. For example, the machine executable instructions can be an operating system device driver, an API, a firmware of a controller of the memory modules, and the like. In some

implementations, the user input received at block 602 may identify a particular set of machine executable instructions to be loaded, and the memory manager 400 can load the user identified set of machine executable instructions. After the memory manager 400 completes blocks 606, 608, 610, and/or 612, the method 600 can end.

[0063] FIG. 7 is a flow diagram of a method 700 for managing memory modules. The method 700 can be implemented in the form of executable instructions stored on a machine-readable medium and/or in the form of electronic circuitry. Although execution of the method 700 is described below with reference to memory manager 300, it should be understood that method 700 can be performed by any other suitable electronic circuitry, such as, for example, the memory manager 1 10 of FIG. 1 , the memory manager 210 of FIG. 2, or the memory manager 400 of FIG. 4. As described above, the memory manager 300 can be communicatively coupled to memory modules of a computing system, the memory modules including a non-volatile memory module and a volatile memory module.

[0064] In some implementations, one or more steps of method 700 can be executed substantially concurrently or in a different order than shown in FIG. 7. In some implementations, method 700 can include more or less steps than are shown in FIG. 7. In some implementations, one or more of the steps of method 700 may, at certain times, be ongoing and/or may repeat. Some blocks of method 700 may be performed in parallel with and/or after method 500 of FIG. 5 and/or method 600 of FIG. 6.

[0065] The method 700 starts, and at block 702, the memory manager 300 can collect status information about the memory modules of the computing system. Block 702 can be analogous to block 502 of method 500 in many respects. As with block 502, block 702 can collect the status information in an ongoing, periodic manner (e.g., at 24-hour periods), and the status information can include an error report regarding the memory modules (which can be similar in many respects to the memory report described above with respect to the management module 1 12 of FIG. 1 ).

[0066] At block 704, the memory manager 300 can predict a failure of the memory modules based on the status information collected at block 702, and more particularly, based on the error report included with the status information. The memory manager 300 can predict the failure of the memory modules by analyzing the error report for patterns in the addresses of reported errors (e.g., row and column addresses of a volatile DIMM). If the number of unique addresses of reported errors on a particular one of the memory modules exceeds a pre-defined threshold, then as a result, block 704 deems the probabilities increased for an uncorrectable error occurring on the particular one of the memory modules and predicts that the particular one of the memory modules may fail. If, on the other hand, the reported errors are substantially from the same address on a particular one of the memory modules, then as a result, block 704 deems the probability of occurrence of an uncorrectable error to be low and no memory modules are predicted to fail.

[0067] At block 706, the memory manager 300 can transmit a notification about a failure prediction to a user interface (e.g., user interface 304) based on the results of the pattern analysis at block 704. For example, if block 704 deems a particular one(s) of the memory modules may fail, the notification can indicate which of the memory modules are predicted to fail. In some implementations, if no memory modules are predicted to fail at block 704, the notification can indicate that no memory modules are predicted to fail (and/or that all memory modules are functioning properly). Block 706 can also include in the notification the results of the pattern analysis performed at block 704.

[0068] At block 708, the memory manager 300 can control the user interface to display the notification transmitted at block 706. After block 708, the method 700 can end.

[0069] In view of the foregoing description, it can be appreciated that a user can efficiently and intuitively manage both non-volatile memory modules and volatile memory modules of a computing system by way of a comprehensive consolidated memory management interface. Accordingly, the functionality of the computing system and of the memory modules of the computing system can be improved. For example, the present disclosure may allow a user to monitor the status (i.e., health) of the computing system and its memory modules, and the user may avoid data loss upon early detection of status problems by migrating data from a failing memory module to healthy memory modules via the interface. As another example of improved functionality, the present disclosure may allow a user to dynamically allocate volatile and non-volatile memory of the computing system. As yet another example of improved functionality, a user may perform remote monitoring and management of the non-volatile and volatile memory modules of the computing system, even in the event of a failure of the computing system, by virtue of an out-of-band remote management aspect of the present disclosure.

[0070] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementation may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the following claims cover such modifications and variations.

Claims

We claim:

1 . A computing system comprising:

memory modules, including a volatile memory module and a nonvolatile memory module;

a memory manager to:

collect status information about the memory modules, the status information including an error report about the memory modules,

set up at least one of the memory modules to operate in at least one of a plurality of operating modes,

load machine executable instructions that control operation of the memory modules,

migrate data between different ones of the memory modules, and

migrate data between different operating modes of the memory modules; and

a user interface to display the status information and to receive user input for management of the memory modules.

2. The computing system of claim 1 , wherein the memory manager is to migrate data between the volatile memory module and the non-volatile memory module based on the user input.

3. The computing system of claim 1 , wherein the operating modes include at least one of a volatile mode, a persistent mode, a block storage mode, an encryption mode, a data acceleration mode, or a fast boot mode.

4. The computing system of claim 1 , wherein

the user interface resides on a first device,

the memory manager resides of a second device separate from the first device, and

the user interface and the memory manager communicate via a network.

5. The computing system of claim 1 , wherein the memory manager is included in a remote management controller for management of the memory modules in the event of a failure of the computing system.

6. The computing system of claim 1 , wherein the non-volatile memory module includes a memory type selected from the group consisting of phase- change memory, spin-transfer torque memory, and resistive random-access memory.

7. A method comprising:

collecting, by a memory manager, status information about memory modules of a computing system, the memory modules including a volatile memory module and a non-volatile memory module;

transmitting the status information from the memory manager to a user interface via a network transmission;

controlling the user interface to display the status information; and receiving, from the user interface, a user input for management of the memory modules based on the status information,

wherein the status information includes an error report about the memory modules.

8. The method of claim 7, wherein the status information about the memory modules includes at least one of an operating mode information, a temperature information, a memory map, a condition information about an equipment associated with the memory modules, or a version identifier of machine executable instructions that control operation of the memory modules.

9. The method of claim 7, further comprising setting up, based on the user input, at least one of the memory modules to operate in at least one of an operating mode selected from among a volatile mode, a persistent mode, a block storage mode, an encryption mode, a data acceleration mode, and a fast boot mode.

10. The method of claim 7, further comprising migrating data between a first memory module of the memory modules to a second memory module of the memory modules, based on the user input.

1 1 . The method of claim 7, further comprising:

predicting a failure of the memory modules based on the status

information;

transmitting a notification about a failure prediction to the user interface based on the predicting; and

controlling the user interface to display the transmitted notification.

12. The method of claim 7, further comprising migrating the data from a first operating mode of the memory modules to a second operating mode of the memory modules, based on the user input,

wherein each of the first operating mode and the second operating mode is a volatile mode, a persistent mode, a block storage mode, an encryption mode, a data acceleration mode, or a fast boot mode.

13. The method of claim 7, further comprising:

identifying if a newer version of machine executable instructions that control operation of the memory modules is available;

in the case where the newer version of the machine executable instructions is available, acquiring the newer version of the machine executable instructions; and

loading the newer version of the machine executable instructions.

14. A non-transitory machine readable medium storing instructions that, when executed by a processor of a memory manager, cause the memory manager to: collect status infornnation about memory modules of a computing system, the memory modules including a volatile memory module and a nonvolatile memory module, the status information including an error report about the memory modules, and at least one of an operating mode information, a temperature information, a memory map, a condition information about an equipment associated with the memory modules, or a version identifier of machine executable instructions that control operation of the memory modules;

evaluate the status information to predict a failure of the memory modules and to generate a failure prediction report;

transmit the status information and the failure prediction report from the memory manager to a user interface via a network transmission;

control the user interface to display the status information and the failure prediction report; and

receive, from the user interface, a user input for management of the memory modules.

15. The non-transitory machine readable medium of claim 14, further comprising instructions that, when executed by the processor, cause the memory manager to:

set up at least one of the memory modules to operate in at least one of a plurality of operating modes, based on the user input;

load machine executable instructions that control operation of the memory modules, based on the user input;

migrate data between different ones of the memory modules, based on the user input; and

migrate data between different operating modes of the memory modules, based on the user input.