Claims:We claim:
1. A method of managing system data for optimizing boot time of a system, the method comprising:
generating, by the memory management system (107), a modified system data by updating a real-time differential data, to the system data stored in a volatile memory unit (103);
compressing, by the memory management system (107), the modified system data upon receiving one or more system commands;
storing, by the memory management system (107), the compressed modified system data in a single page of a non-volatile memory unit (105); and
reading, by the memory management system (107), the single page from the non-volatile memory unit (105) to the volatile memory unit (103), upon receiving a system boot request from one or more system boot modules associated with the memory management system (107), thereby optimizing the boot time of the system.
2. The method as claimed in claim 1 further comprises decompressing, by the memory management system (107), the compressed modified system data after reading the single page to the volatile memory unit (103) for booting the system.

3. The method as claimed in claim 1, wherein the single page read from the non-volatile memory unit (105) is a last updated page comprising the compressed modified system data.

4. The method as claimed in claim 1, wherein size of the compressed modified system data is less than or equal to page size in the non-volatile memory unit (105).

5. The method as claimed in claim 1, wherein the one or more system commands are at least one of “Take Snapshot” and “Commit Logs”.

6. A method of managing system data for optimizing boot time of a system, the method comprising:
identifying, by the memory management system (107), one of one or more predefined regions configured in a non-volatile memory unit (105) to be used for storing a modified system data, wherein the modified system data is generated by updating, in a volatile memory unit (103), a real-time differential data to a corresponding part of the system data;
compressing, by the memory management system (107), the modified system data upon receiving a first predefined system command;
storing, by the memory management system (107), the compressed modified system data in a single page belonging to the one of the one or more predefined regions in the non-volatile memory unit (105); and
reading, by the memory management system (107), the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions from the non-volatile memory unit (105) to the volatile memory unit (103), upon receiving a system boot request from one or more system boot modules associated with the memory management system (107), thereby optimizing the boot time of the system.
7. The method as claimed in claim 6 further comprises updating, by the memory management system (107), a region header associated with each of the one or more predefined regions upon storing the compressed modified system data.

8. The method as claimed in claim 7, wherein the region header comprises information related to page Identifier (ID), region ID and a region-page map data that indicates real-time position of the compressed modified system data in the non-volatile memory unit (105).

9. The method as claimed in claim 6, wherein the part of the system data corresponding to the real-time differential data is identified based on one or more predefined policies.

10. The method as claimed in claim 6, wherein the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions are identified based on a region header associated with each of the one or more predefined regions.

11. The method as claimed in claim 6, wherein the single page read from the one of the one or more predefined regions is a last updated page comprising the compressed modified system data in the one of the one or more predefined regions.

12. The method as claimed in claim 6 further comprises decompressing, by the memory management system (107), the compressed modified system data present in the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions, in the volatile memory unit (103) for booting the system.

13. The method as claimed in claim 6, wherein size of the compressed modified system data corresponding to the one of the one or more predefined regions is less than or equal to page size in the non-volatile memory unit (105).

14. The method as claimed in claim 6, wherein the first predefined system command is “Commit Logs”.

15. The method as claimed in claim 6 further comprises

compressing, by the memory management system (107), the system data and the modified system data upon receiving a second predefined system command; and

storing, by the memory management system (107), the compressed system data and the compressed modified system data to a corresponding one of the one or more predefined regions.

16. The method as claimed in claim 15, wherein the second predefined system command is “Take snapshot”.

17. The method as claimed in claim 1, wherein the one of the one or more predefined regions for storing the modified system data is identified using a transaction module (233) associated with the memory management system (107), based on a start address and an end address where the real-time differential data is updated to the system data, a base address of the system data, and a size of the modified system data.

18. A memory management system (107) for optimizing boot time of a system, the memory management system (107) comprising:
a processor (109); and
a memory (113) communicatively coupled to the processor (109), wherein the memory (113) stores the processor-executable instructions, which, on execution, causes the processor (109) to:
generate a modified system data by updating a real-time differential data, to the system data stored in a volatile memory unit (103);
compress the modified system data upon receiving one or more system commands;
store the compressed modified system data in a single page of a non-volatile memory unit (105); and
read the single page from the non-volatile memory unit (105) to the volatile memory unit (103), upon receiving a system boot request from one or more system boot modules associated with the memory management system (107), thereby optimizing the boot time of the system.
19. The memory management system (107) as claimed in claim 18, wherein the processor (109) is further configured to decompress the compressed modified system data after reading the single page to the volatile memory unit (103) for booting the system.

20. The memory management system (107) as claimed in claim 18, wherein the single page read from the non-volatile memory unit (105) is a last updated page comprising the compressed modified system data.

21. The memory management system (107) as claimed in claim 18, wherein size of the compressed modified system data is less than or equal to page size in the non-volatile memory unit (105).

22. The memory management system (107) as claimed in claim 18, wherein the one or more system commands are at least one of “Take Snapshot” and “Commit Logs”.

23. A memory management system (107) for optimizing boot time of a system, the memory management system (107) comprising:
a processor (109); and
a memory (113) communicatively coupled to the processor (109), wherein the memory (113) stores the processor-executable instructions, which, on execution, causes the processor (109) to:
identify one of one or more predefined regions configured in a non-volatile memory unit (105) to be used for storing a modified system data, wherein the modified system data is generated by updating, in a volatile memory unit (103), a real-time differential data to a corresponding part of the system data;
compress the modified system data upon receiving a first predefined system command;
store the compressed modified system data in a single page belonging to the one of the one or more predefined regions in the non-volatile memory unit (105); and
read the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions from the non-volatile memory unit (105) to the volatile memory unit (103), upon receiving a system boot request from one or more system boot modules associated with the memory management system (107), thereby optimizing the boot time of the system.
24. The memory management system (107) as claimed in claim 23, wherein the processor (109) is further configured to update a region header associated with each of the one or more predefined regions upon storing the compressed modified system data.

25. The memory management system (107) as claimed in claim 24, wherein the region header comprises information related to page Identifier (ID), region ID and a region-page map data that indicates real-time position of the compressed modified system data in the non-volatile memory unit (105).

26. The memory management system (107) as claimed in claim 23, wherein the processor (109) identifies the part of the system data corresponding to the real-time differential data based on one or more predefined policies.

27. The memory management system (107) as claimed in claim 23, wherein the processor (109) identifies the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions, based on a region header associated with each of the one or more predefined regions.

28. The memory management system (107) as claimed in claim 23, wherein the single page read from the one of the one or more predefined regions is a last updated page comprising the compressed modified system data in the one of the one or more predefined regions.

29. The memory management system (107) as claimed in claim 23, wherein the processor (109) is further configured to decompress the compressed modified system data present in the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions, in the volatile memory unit (103) for booting the system.

30. The memory management system (107) as claimed in claim 23, wherein size of the compressed modified system data corresponding to the one of the one or more predefined regions is less than or equal to page size in the non-volatile memory unit (105).

31. The memory management system (107) as claimed in claim 23, wherein the first predefined system command is “Commit Logs”.

32. The memory management system (107) as claimed in claim 23, wherein the processor (109) is further configured to:

compress the system data and the modified system data upon receiving a second predefined system command; and

store the compressed system data and the compressed modified system data to a corresponding one of the one or more predefined regions.

33. The memory management system (107) as claimed in claim 32, wherein the second predefined system command is “Take snapshot”.

34. The memory management system (107) as claimed in claim 23, wherein the processor (109) identifies the one of the one or more predefined regions for storing the modified system data using a transaction module (233) associated with the memory management system (107), based on a start address and an end address where the real-time differential data is updated to the system data, a base address of the system data, and a size of the modified system data.

Dated this 22nd day of January 2018

SWETHA S.N.
IN/PA-2123
OF K & S PARTNERS
AGENT FOR THE APPLICANT

, Description:FORM 2
THE PATENTS ACT 1970
[39 OF 1970]
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
[See section 10 and rule 13]

TITLE: “METHOD AND MEMORY MANAGEMENT SYSTEM FOR MANAGING SYSTEM DATA FOR OPTIMIZING BOOT TIME OF SYSTEM”

Name and Address of the Applicant:
TOSHIBA Software (India) Pvt. Ltd., #3A, Essae Vaishnavi Solitaire, III Block, Koramangala, Bangalore – 560034

Nationality: India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD

The present subject matter is related, in general to memory management and more particularly, but not exclusively to a method and a memory management system for managing system data for optimizing boot time of a system.

BACKGROUND

Generally, there are different non-volatile memory devices for storing various types of data. One such non-volatile memory devices based on which the present disclosure would be discussed is a Solid-State Device (SSD). SSD is a solid-state storage device that uses integrated circuit assemblies as memory to store data persistently. The SSD comprises a System-on-a-Chip (SoC) and operates using an internal SSD firmware that provides access to user data read and write operations via a look up table. Along with the look up table, the SSD firmware provides features to manage non-volatile memory storage that comprises a series of NAND flash chips connected to the SSD SoC. Each NAND flash chip comprises multiple blocks and these blocks are arranged in multiple planes to allow parallel access of system data stored within the flash chip. Further, each block consists of multiple pages where the system data is stored.

The non-volatile memory storage handles various device boot methods such as normal power off/ power on mode, different levels of sleep mode, unexpected power off and the like. System data required for booting the system should be periodically updated from a volatile memory storage to the non-volatile memory storage such that the system restores with a well-known state in every power cycle. Currently, real-time differential data, which indicates changes or updates to the system data are initially stored/recorded in the volatile memory storage. The process of recording the real-time differential data in the volatile memory storage is known as “add logs”. The real-time differential data is accumulated in the volatile memory storage and system commands are received by the SSD firmware.. Upon receiving the system commands, the real-time differential data accumulated over a period of time is stored in the non-volatile memory storage. Further, when the system receives a system boot request, the system data present in the form of snapshots in the non-volatile memory storage is restored into the volatile memory storage.

Further, each log corresponding to the real-time differential data stored in the non-volatile memory storage is read and appropriately the system data restored into the volatile memory storage is modified based on the logs read one after the other. The modified system data thus obtained after reading all the logs is used for booting the system. Upon receiving the system command such as “take snapshot”, the entire modified system data is stored/recorded in the non-volatile memory storage. This cycle of storing logs in the non-volatile memory storage and modifying the system data by reading the logs at the time of system boot repeats continuously. However, the current method poses certain disadvantages regarding time taken for the system boot. In the current method, the time taken for the system boot varies based on number of logs recorded in the non-volatile memory storage prior to the system boot request. Therefore, the time taken for the system boot is inconsistent. Also, storing all the logs in the non-volatile memory storage separately leads to abundant usage of storage space.

The information disclosed in this background section of the disclosure is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art

SUMMARY

One or more shortcomings of the prior art are overcome, and additional advantages are provided through the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.
The present disclosure provides a method of managing system data for optimizing boot time of a system. The method comprises generating, by a memory management system, a modified system data by updating a real-time differential data, to the system data stored in a volatile memory unit. Further, the memory management system comprises compressing the modified system data upon receiving one or more system commands. Furthermore, the memory management system stores the compressed modified system data in a single page of a non-volatile memory unit. Finally, the memory management system reads the single page from the non-volatile memory unit to the volatile memory unit, upon receiving a system boot request from one or more system boot modules associated with the memory management system, thereby optimizing the boot time of the system.
Further, the present disclosure provides a method of managing system data for optimizing boot time of a system. The method comprising identifying, by a memory management system, one of one or more predefined regions configured in a non-volatile memory unit to be used for storing a modified system data. The modified system data is generated by updating, in a volatile memory unit, a real-time differential data to a corresponding part of the system data. Further, the memory management system compresses the modified system data upon receiving a first predefined system command. Furthermore, the memory management system stores the compressed modified system data in a single page belonging to the one of the one or more predefined regions in the non-volatile memory unit. Finally, the memory management system, reads the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions from the non-volatile memory unit to the volatile memory unit, upon receiving a system boot request from one or more system boot modules associated with the memory management system, thereby optimizing the boot time of the system.
Furthermore, the present disclosure comprises a memory management system for managing system data for optimizing boot time of a system. The memory management system comprises a processor and a memory communicatively coupled to the processor. The memory stores the processor-executable instructions, which, on execution, causes the processor to generate a modified system data by updating a real-time differential data, to the system data stored in a volatile memory unit. Further, the processor compresses the modified system data upon receiving one or more system commands. Furthermore, the processor stores the compressed modified system data in a single page of a non-volatile memory unit. Finally, the processor reads the single page from the non-volatile memory unit to the volatile memory unit, upon receiving a system boot request from one or more system boot modules associated with the memory management system, thereby optimizing the boot time of the system.
Further, the present disclosure comprises a memory management system for managing system data for optimizing boot time of a system. The memory management system comprises a processor and a memory communicatively coupled to the processor. The memory stores the processor-executable instructions, which, on execution, causes the processor to identify one of one or more predefined regions configured in a non-volatile memory unit to be used for storing a modified system data. The modified system data is generated by updating, in a volatile memory unit, a real-time differential data to a corresponding part of the system data. Further, the processor compresses the whole system data upon receiving a first predefined system command. Furthermore, the processor stores the compressed modified system data in a single page belonging to the one of the one or more predefined regions in the non-volatile memory unit. Finally, the processor reads the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions from the non-volatile memory unit to the volatile memory unit, upon receiving a system boot request from one or more system boot modules associated with the memory management system, thereby optimizing the boot time of the system.
The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.
BRIEF DESCRIPTION OF THE ACCOMPANYING DIAGRAMS
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:
FIG.1 shows an exemplary architecture for managing system data for optimizing boot time of a system in accordance with some embodiments of the present disclosure;
FIG.2A shows a detailed block diagram of a memory management system for managing system data for optimizing boot time of a system in accordance with some embodiments of the present disclosure;
FIG.2B - FIG.2E show exemplary management of system data in the volatile memory unit and the non-volatile memory unit by the memory management system in accordance with some embodiments of the present disclosure;
FIG.3A illustrates a flowchart showing method of managing system data for optimizing boot time of a system whose system data may be compressed to a single page, in accordance with some embodiments of the present disclosure;
FIG.3B illustrates a flowchart showing method of managing system data for optimizing boot time of a system whose system data may be compressed to more than a single page, in accordance with some embodiments of the present disclosure; and
FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.
It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION
In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.
While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.
The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.
The present disclosure provides a method and a memory management system for managing system data for optimizing boot time of a system. The memory management system generates a modified system data by updating a real-time differential data, to the system data stored in a volatile memory unit associated with the memory management system. The feature of updating the real-time differential data directly to the system data in the volatile memory unit, instead of accumulating the real-time differential data as various logs over a period of time, eliminates the differential logs methodology followed in the existing techniques which face the limitations of consuming abundant memory space and increasing boot time of the system. Further, the memory management system comprises compressing the modified system data upon receiving one or more system commands. In some embodiments, size of the compressed modified system data is less than or equal to page size in a non-volatile memory unit associated with the memory management system. Further, the memory management system stores the compressed modified system data in a single page of the non-volatile memory unit.

The feature of storing the modified system data in the non-volatile memory unit in a compressed format reduces amount of memory space used for storing the modified system data. Further, the memory management system reads the single page from the non-volatile memory unit to the volatile memory unit, upon receiving a system boot request from one or more system boot modules associated with the memory management system. Upon reading the single page, the memory management system decompresses the compressed modified system data present in the single page for booting the system. Since, the memory management system reads and decompresses contents of only the single page in the volatile memory unit for booting the system in every iteration, the method achieves an optimized as well as a constant system boot time.

In some scenarios, size of compressed system data or the modified system data may not be less than or equal to the page size in the non-volatile memory unit. In such scenarios, the non-volatile memory unit configured with one or more predefined regions may be used to store the compressed system data or the compressed modified data. Initially, the memory management system may generate the modified system data by updating the real-time differential data to a corresponding part of the system data in the volatile memory unit. Further, the memory management system may identify one of one or more predefined regions configured in the non-volatile memory unit to be used for storing the modified system data. Upon receiving the first predefined system command, the memory management system may compress the modified system data such that, the compressed modified system data, belonging to the one of the one or more predefined regions as a result of the predefined classification, may fit into a single page of the non-volatile memory unit. As an example, the first predefined system command may include, but not limited to, “Commit Logs”. Upon compressing the modified system data, the memory management system stores the compressed modified system data in a single page belonging to the one of the one or more predefined regions in the non-volatile memory unit. Further, a region header associated with each of the one or more predefined regions is updated upon storing the compressed modified system data. In some embodiments, the region header may include, but not limited to, information related to page Identifier (ID), region ID and a region-page map data that indicates real-time position of the compressed modified system data in the non-volatile memory unit. The feature of updating the real-time differential data to only the corresponding part of the system data, and storing the modified system data thus obtained in the corresponding predefined region of the non-volatile memory unit, instead of storing the entire system data along with the modified system data for every iteration, reduces the unwanted usage of the memory space in the non-volatile memory unit.

Further, upon receiving a system boot request from one or more system boot modules associated with the memory management system, the memory management system reads the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions from the non-volatile memory unit to the volatile memory unit, thereby optimizing the boot time of the system. Similarly, the memory management system stores the compressed system data in turn including the modified system data in the corresponding one or more predefined regions, upon receiving a second predefined system command. In some embodiments, the second predefined system command may include, but not limited to, “Take Snapshot”. Finally, the memory management system, reads the single page from the one of the one or more predefined regions and a last updated page from the non-volatile memory unit to the volatile memory unit, upon receiving a system boot request from one or more system boot modules associated with the memory management system. Further, the memory management system may decompress the compressed modified system data present in the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions, in the volatile memory unit for booting the system. Since, the memory management system reads and decompresses contents of only the single page read from each of the one or more predefined regions for booting the system in every iteration, the method achieves an optimized as well as a constant system boot time.

In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

FIG.1 shows an exemplary architecture for managing system data for optimizing boot time of a system in accordance with some embodiments of the present disclosure.
The architecture 100 comprises a volatile memory unit 103, a non-volatile memory unit 105 and a memory management system 107. As an example, the volatile memory unit 103 may be a Random-Access Memory (RAM), a Dynamic RAM (DRAM), a Synchronous DRAM (SDRAM) and the like. As an example, the non-volatile memory unit 105 may be a Solid-State Device (SSD), a Hard Disk Drive (HDD), floppy disks, optical disks and the like. Henceforth, in the present disclosure, the process for managing system data for optimizing boot time of a system is explained considering design architecture of the non-volatile memory unit 105 “SSD”. However, this should not be considered as a limitation of the present disclosure.
In some embodiments, the volatile memory unit 103, the non-volatile memory unit 105 and the memory management system 107 may be configured within a single system as shown in the FIG.1. In some embodiments, the volatile memory unit 103, the non-volatile memory unit 105 and the memory management system 107 may be associated with each other via a communication network (not shown in the FIG.1). As an example, the communication network may be at least one of a wired communication network and a wireless communication network.
The memory management system 107 comprises a processor 109, an Input/Output (I/O) interface 111 and a memory 113. The processor 109 causes the I/O interface 111 to interact with the volatile memory unit 103 and the non-volatile memory unit 105 to manage the system data. The I/O interface 111 may access a real-time differential data received by the volatile memory unit 103. In an embodiment, the real-time differential data may include, but not limited to, an update, addition or deletion related to system data. In some embodiments, the system data may be data required for a system boot. The processor 109 may update the real-time differential data to the system data present in the volatile memory unit 103 to generate a modified system data in real-time. Further, upon receiving one or more system commands, the processor 109 may compress the modified system data such that, the compressed modified system data may fit into a single page of the non-volatile memory unit 105. As an example, the one or more system commands may include, but not limited to, “Take Snapshot” and “Commit Logs”. The system command “Take Snapshot” may require storing the complete compressed modified system data in the non-volatile memory unit 105, whereas the system command “Commit Logs” may require storing only modified part of the system data in the non-volatile memory unit 105. Further, the processor 109 may store the compressed modified system data into the single page of the non-volatile memory unit 105. In some embodiments, the single page is a first available empty page in the non-volatile memory unit 105. Since the complete modified system data is compressed into the single page, the processor 109 stores the complete compressed modified system data in the non-volatile memory unit 105 even when the system command received may be “Commit Logs”. In some embodiments, size of the compressed modified system data stored in the single page of the non-volatile memory unit 105 may be less than or equal to page size in the non-volatile memory unit 105.
Further, upon receiving a system boot request from one or more system boot modules associated with the memory management system 107, the processor 109 may read the single page comprising the compressed modified system data from the non-volatile memory unit 105 into the volatile memory unit 103. In some embodiments, the single page read from the non-volatile memory unit 105 may be a last updated page comprising the compressed modified system data. Upon reading the single page, the processor 109 may decompress the compressed modified system data present in the single page for booting the system.
In some embodiments, the system data when compressed may require more than a single page for storage. In such scenarios, the processor 109 may store the compressed system data or the compressed modified system data in the non-volatile memory unit 105 configured with one or more predefined regions. In some embodiments, requirement of the one or more predefined regions and the number of the one or more predefined regions in the non-volatile memory unit 105 may be computed/predicted based on the size of the system data during an initial design stage of the non-volatile memory unit 105. Based on the computation/prediction, the non-volatile memory unit 105 may be designed to meet the requirement. In some embodiments, each of the one or more predefined regions may be in the form of an uncompressed fixed size page of the non-volatile memory unit 105. Therefore, the number of the one or more predefined regions present in the non-volatile memory unit 105 may be equal to maximum number of pages that may be required for storing the compressed system data or the compressed modified system data in the non-volatile memory unit 105. Further, in some embodiments, each of the one or more predefined regions in the non-volatile memory unit 105 may be configured to store certain type of the system data obtained based on a predefined classification. As an example, if the system data can be compressed into maximum 5 pages depending upon size of each page, then the non-volatile memory unit 105 would be configured with 5 predefined regions for storing the compressed system data. Further, each of the 5 predefined regions may store only the type of the system data assigned to each of the 5 predefined regions based on the predefined classification. As an example, the system data may be broadly classified as, but not limited to, Frontend system data and Backend system data. As an example, the Frontend system data may include Device Interface Information such as SATA, NVMe and the like, Application information such as file system data and user specific data, and the like. As an example, the Backend system data may include Root Block Table such as Firmware Block, Device Property, and the like, User Lookup table that provides non-volatile address map for user space address, System Map table that indicates physical blocks constructed as logical block to achieve maximum read write performance, wear levelling control information structure, compaction control information Structure, write controller control information structure, system present mode such as Read-Write Mode, Read Only Mode, Power Save Mode, and the like, error and statistic information for the system maintenance and support, and the like. In the scenario where the non-volatile memory unit 105 comprises the one or more predefined regions, initially, the processor 109 may update the real-time differential data received by the volatile memory unit 103 to a part of the system data to which the real-time differential data may belong. The part of the system data to which the real-time differential data is updated may be a modified system data. Further, the processor 109 may identify one of the one or more predefined regions where the modified system data may be stored. In some embodiments, the processor 109 may identify the one of the one or more predefined regions based on a start address and an end address where the real-time differential data is updated to the system data, a base address of the system data, and a size of the modified system data. In some embodiments, updating the system data may include changing values or information related to the system data in accordance with real-time scenarios, without increasing or decreasing size of the system data. Further, upon receiving a first system command, the processor 109 may compress the modified system data such that, the compressed modified system data, belonging to the one of the one or more predefined regions as a result of the predefined classification, may fit into the single page of the non-volatile memory unit 105. As an example, the first system command may include, but not limited to, “Commit Logs”, that may require storing only the modified system data in the non-volatile memory unit 105. In some embodiments, size of the compressed modified system data corresponding to the one of the one or more predefined regions is less than or equal to page size in the non-volatile memory unit 105. Upon compressing the modified system data, the processor 109 may store the compressed modified system data in the single page belonging to the one of the one or more predefined regions identified by the processor 109. Further, upon storing the compressed modified system data in the non-volatile memory unit 105, the processor 109 may update a region header associated with each of the one or more predefined regions. In some embodiments, the region header comprises information related to page Identifier (ID), region ID and a region-page map data that indicates real-time position of the compressed modified system data in the non-volatile memory unit 105.
Further, upon receiving the system boot request from the one or more system boot modules associated with the memory management system 107, the processor 109 may read the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions from the non-volatile memory unit 105 to the volatile memory unit 103. In some embodiments, the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions are identified based on the region header associated with each of the one or more predefined regions.
Further, the processor 109 may decompress the compressed modified system data present in the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions, in the volatile memory unit 103 for booting the system.
In some embodiments, the processor 109 may receive a second predefined system command. As an example, the second predefined system command may include, but not limited to, “Take Snapshot”. Upon receiving the second system command, the processor 109 may compress the system data along with the modified system data present in the volatile memory unit 103. Further, the processor 109 may store the compressed system data and the compressed modified system data to a corresponding one of the one or more predefined regions based on the predefined classification associated with each of the one or more predefined regions.
FIG.2A shows a detailed block diagram of a memory management system for managing system data for optimizing boot time of a system in accordance with some embodiments of the present disclosure.
In one implementation, the memory management system 107 comprises data 203 and modules 205. As an example, the data 203 may be stored in memory 113 configured in the memory management system 107. In one embodiment, the data 203 may include a policy data 211, a transaction data 213 and other data 215. In the illustrated FIG.2A, the modules 205 are described here in detail.
In one embodiment, the data 203 may be stored in the memory 113 in the form of various data structures. Additionally, the data 203 can be organized using data models, such as relational or hierarchical data models. The other data 215 may store data, including temporary data and temporary files, generated by the modules 205 for performing the various functions of the memory management system 107.
In an embodiment, the data 203 stored in the memory 113 may be processed by the modules 205 of the memory management system 107. The modules 205 may be stored within the memory 113. In an example, the modules 205, communicatively coupled to a processor 109 configured in the memory management system 107, may also be present outside the memory 113 as shown in FIG.2A and implemented as hardware. As used herein, the term module refers to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
In an embodiment, the modules 205 may include, for example, a generating module 221, a compressing module 223, a storing module 225, a system boot module 227, a decompressing module 229, an identifying module 231, a transaction module 233 and other modules 235. The other modules 235 may be used to perform various miscellaneous functionalities of the memory management system 107. It will be appreciated that such modules 205 may be represented as a single module or a combination of different modules.
In some embodiments, the generating module 221 may generate a modified system data in a volatile memory unit 103 associated with the memory management system 107. The generating module 221 may generate the modified system data by updating a real-time differential data, to a system data stored in the volatile memory unit 103. In some embodiments, the real-time differential data may include, but not limited to, an update, addition or deletion related to the system data, such that total size of the system data remains unchanged.
In some embodiments, the compressing module 223 may compress the modified system data upon receiving one or more system commands. As an example, the one or more system commands may include, but not limited to, “Take Snapshot” and “Commit Logs”. The system command “Take Snapshot” may require storing the complete compressed modified system data in the non-volatile memory unit 105, whereas the system command “Commit Logs” may require storing only modified part of the system data in the non-volatile memory unit 105. In some embodiments, the compressing module 223 may use one or more predefined techniques for compressing the modified system data. In some embodiments, size of the compressed modified system data may be less than or equal to page size in a non-volatile memory unit 105 associated with the memory management system 107. In some embodiments, when the size of the compressed modified system data is less than the page size, then the remaining memory space is filled with zeros before storing the compressed modified system data in the non-volatile memory unit 105. As an example, consider that the page size in the non-volatile memory unit 105 is 16KB. However, upon compressing the modified system data, the compressed modified system data may be of size 12KB. Therefore, the remaining memory space of 4KB is filled with zeros.
Further, in some embodiments, the storing module 225 may store the compressed modified system data in a single page of the non-volatile memory unit 105. In some embodiments, the single page may be a first available empty page in the non-volatile memory unit 105.
In some embodiments, the system boot module 227 may read the single page comprising the compressed modified system data from the non-volatile memory unit 105 into the volatile memory unit 103 upon receiving a system boot request from one or more system boot modules associated with the memory management system 107. In some embodiments, the single page read from the non-volatile memory unit 105 may be a last updated page comprising the compressed modified system data.
In some embodiments, the decompressing module 229 may decompress the compressed modified system data present in the single page for booting the system. The decompressing module 229 may use the one or more predefined techniques to decompress the compressed modified system data.
Further, the system boot module 227 may compute time taken for booting the system. In some embodiments, the time taken for booting the system may be computed as shown in the below Equation 1.
Time taken for booting the system = (T1 + T2 + T3) -------------- Equation 1
In the above Equation 1,
T1 indicates time required for identifying a last updated page in the non-volatile memory unit 105;
T2 indicates time taken to read the single page from the non-volatile memory unit 105; and
T3 indicates time taken to decompress the single page read from the non-volatile memory unit 105.
Since, the memory management system 107 may read and decompress only the single page for every system boot request, the time taken for booting the system will remain constant for every system boot request. Also, the time taken for booting the system may be optimized by a large extent when compared to the existing techniques known in the art.
In some embodiments, the system data when compressed may require more than a single page for storage. In such scenarios, the processor 109 may store the compressed system data or the compressed modified system data in the non-volatile memory unit 105 configured with one or more predefined regions.
In the scenarios where the non-volatile memory unit 105 configured with the one or more predefined regions is used, the generating module 221 may generate a modified system data by updating the real-time differential data received by the volatile memory unit 103 to a part of the system data to which the real-time differential data may belong. The part of the system data to which the real-time differential data is updated may be the modified system data. In some embodiments, the identifying module 231 may identify part of the system data to which the real-time differential data belongs, based on one or more predefined policies. The one or more predefined policies may be stored as the policy data 211. In some embodiments, the one or more predefined policies may include, but not limited to, a predefined classification of the system data.
In some embodiments, the transaction module 233 may receive a start address and an end address where the real-time differential data is updated to the system data in the volatile memory unit 103, a base address of the system data in the volatile memory unit 103 and a size of the modified system data, from the volatile memory unit 103. The data received from the volatile memory unit 103 may be stored as the transaction data 213. Based on the transaction data 213, the transaction module 233 may identify one of the one or more predefined regions of the non-volatile memory unit 105, where the modified system data may be stored. In some embodiments, the modified system data may extend to more than one predefined region. In such scenarios, the transaction module 233 may identify the one or more predefined regions in which the modified system data may be split and stored.
In some embodiments, the compressing module 223 may compress the modified system data upon receiving a first predefined system command. As an example, the first predefined system command may include, but not limited to, “Commit Logs”, that may require storing only the modified system data in the non-volatile memory unit 105. In some embodiments, size of the compressed modified system data corresponding to the one of the one or more predefined regions may be less than or equal to the page size in the non-volatile memory unit 105. In some embodiments, when the size of the compressed modified system data is less than the page size, then the remaining memory space is filled with zeros before storing the compressed modified system data in the non-volatile memory unit 105. As an example, consider that the page size in the non-volatile memory unit 105 is 16KB. However, upon compressing the modified system data, the compressed modified system data may be of size 12KB. Therefore, the remaining memory space of 4KB is filled with zeros.
Further, in some embodiments, the storing module 225 may store the compressed modified system data in the single page belonging to the one of the one or more predefined regions identified by the transaction module 233. Upon storing the compressed modified system data in the non-volatile memory unit 105, a processor 109 of the memory management system 107 may update a region header associated with each of the one or more predefined regions. In some embodiments, the region header comprises information related to page Identifier (ID), region ID and a region-page map data that indicates real-time position of the compressed modified system data in the non-volatile memory unit 105. In some embodiments, size of the region header would be equal to the number of the one or more predefined regions configured in the non-volatile memory unit 105. As an example, if the non-volatile memory unit 105 is configured with 5 regions, then the size of the region header would be 5 bytes or in other words, a 5 bytes region header would be associated with each of the one or more predefined regions.
In some embodiments, the system boot module 227 may read the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions, from the non-volatile memory unit 105 to the volatile memory unit 103, upon receiving the system boot request. The system boot module 227 may identify the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions are identified based on the region header associated with each of the one or more predefined regions. Further, the system boot module 227 may read the single page from the one of the one or more predefined regions and the last updated page from each of rest of the one or more predefined regions parallelly. In some embodiments, the single page read from the one of the one or more predefined regions may be a last updated page comprising the compressed modified system data in the one of the one or more predefined regions.
In some embodiments, the decompressing module 229 may decompress the compressed modified system data present in the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions, in the volatile memory unit 103 for booting the system. The decompressing module 229 may decompress the compressed modified system data belonging to the single page and the last updated page of each of the rest of the one or more predefined regions in the volatile memory unit 103, parallelly, while the system boot module 227 may be performing the read action in the non-volatile memory unit 105.
In some embodiments, the compressing module 223 may receive a second predefined system command. As an example, the second predefined system command may include, but not limited to, “Take Snapshot”. Upon receiving the second system command, the compressing module 223 may compress the system data along with the modified system data present in the volatile memory unit 103. Further, the storing module 225 may store the compressed system data and the compressed modified system data to a corresponding one of the one or more predefined regions based on the predefined classification.
Further, the system boot module 227 may compute time taken for booting the system. In some embodiments, the time taken for booting the system may be computed as shown in the below Equation 2.
Time taken for booting the system = (RT1 + RT2 + RT3) -------------- Equation 2
In the above Equation 2,
RT1 indicates time required for identifying the last updated page from each of the one or more predefined regions;
RT2 indicates total time taken to read a single page from each of the one or more predefined regions parallelly; and
RT3 indicates time taken to decompress the single page read from each of the one or more predefined regions parallelly.
Since, the memory management system 107 may read and decompress only a single page from each of the one or more predefined regions for every system boot request, the time taken for booting the system will remain constant for every system boot request. Further, the system boot module 227 may read the single page from each of the one or more predefined regions parallelly. Also, the decompressing module 229 may decompress each single page read from the non-volatile memory unit 105, in the volatile memory unit 103, parallelly, while the system boot module 227 may be performing the read action in the non-volatile memory unit 105. Therefore, the time taken for booting the system may be optimized by a large extent when compared to the existing techniques known in the art.
Henceforth, the process for managing system data for optimizing boot time of the system is explained with the help of one or more examples for better understanding of the present disclosure. However, the one or more examples should not be considered as limitation of the present disclosure.

Consider an exemplary scenario, where the complete system data can be compressed into a single page and stored in the non-volatile memory unit 105. In this scenario, irrespective of whether the system command is “Take Snapshot” or “Commit Logs”, the compressing module 223 may store the complete compressed system data including the modified system data into the non-volatile memory unit 105.

Consider the FIG.2B, where the system data or the modified system data may not exceed a size of four pages or 64KB as shown in the Table 245a. The generating module 221 may generate the modified system data by updating the real-time differential data to the system data in the volatile memory unit 103. Upon generating the modified system data, the processor 109 may receive a “Take Snapshot” system command (also referred as a commit request). As shown in the Table 245b in the FIG.2B, the system command “Take Snapshot” received in a first iteration is assigned with a Request Identifier (ID) “0”. Upon receiving the “Take Snapshot” system command, the compressing module 223, may compress the modified system data such that the modified system data fits into a single page of the non-volatile memory unit 105. Upon compressing the modified system data, the storing module 225 may store the compressed modified system data in the single page or alternatively referred as a first empty page in the non-volatile memory unit 105. As shown in the Table 245c in the FIG.2B, the compressed modified system data of size 16KB, is stored in the single page of the non-volatile memory unit 105 having the Page ID “0”.
The above-mentioned method of generating the modified system data, compressing the modified system data and storing the compressed modified system data of the size 16KB in successive single pages of the non-volatile memory unit 105 may be performed iteratively until the processor 109 receives the system boot request from the one or more system boot modules. Upon receiving the system boot request, the system boot module 227 may read the last updated page comprising the compressed modified system data from the non-volatile memory unit 105, among the other single pages stored in the non-volatile memory unit 105. In some embodiments, only the last updated page is read from the non-volatile memory unit 105 because the compressed modified system data stored in the non-volatile memory unit 105 in every iteration comprises a latest version of the system data in the form of the compressed modified system data. As shown in the FIG.2B, consider that the single page having the Page ID “4” is the last updated page in the non-volatile memory unit 105 comprising the compressed modified system data. Therefore, the system boot module 227 may read the single page having the Page ID “4” from the non-volatile memory unit 105 to the volatile memory unit 103. Upon reading the single page, the decompressing module 229 may decompress the compressed modified system data present in the single page to obtain the latest version of the system data for booting the system.
Upon booting the system, the system boot module 227 may compute the time taken for booting the system using the below given Equation 1.
Time taken for booting the system = (T1 + T2 + T3) -------------- Equation 1
Consider that the time required (T1) for identifying the last updated page in the non-volatile memory unit 105 is 50 microseconds (us). Time taken (T2) for reading the single page from the non-volatile memory unit 105 is 100us and time taken (T3) for decompressing the single page in the volatile memory unit 103 is 50us. Therefore, by substituting the values of T1, T2 and T3, the total time taken for booting the system is 50us +100us+50us = 200us
Therefore, the total time taken for booting the system is 200us or 0.2ms. This is an optimized system boot time, that would remain constant for every system boot, unlike the existing art that provides a varying system boot time for every system boot.
Consider another exemplary scenario, where the complete system data cannot be compressed and stored in a single page of the non-volatile memory unit 105. In this scenario, upon receiving the system command “Take Snapshot”, the system data along with the modified system data would be compressed and stored in the non-volatile memory unit 105. Alternatively, upon receiving the system command “Commit Logs”, only the modified system data may be compressed and stored in the non-volatile memory unit 105.
Consider the FIG.2C, where maximum size of the system data does not exceed a size of 20 pages of the non-volatile memory unit 105 (size of each page is 16KB) or 320KB as shown in the Table 247a. At the initial design stage of the non-volatile memory unit 105, number of one or more predefined regions required in the non-volatile memory unit 105 may be computed based on the maximum size of the system data.
Consider a compression ratio of 4:1 is applied for compressing the system data of size 320KB stored in 20 pages. In some embodiments, the compression ratio 4:1 indicates that, 4 pages of the system data i.e. 64KB of the system data may be compressed into 1 page of size 16KB. Therefore, 20 pages of the system data would be compressed into 5 pages of 16KB each i.e. size of the total compressed system data would be 80KB. In some embodiments, the number of the one or more predefined regions present in the non-volatile memory unit 105 may be equal to maximum number of pages that may be required for storing the total compressed system data in the non-volatile memory unit 105. Based on the above calculation, at the initial design stage, the non-volatile memory unit 105 may be configured with 5 predefined regions since 5 pages are required for storing the total compressed system data. Further, in some embodiments, each of the one or more predefined regions in the non-volatile memory unit 105 may be configured to store certain type of the system data obtained based on a predefined classification. As an example, one of the predefined regions may be configured to store only the type of the system data related to Operating System (OS).
Initially, the generating module 221 may generate a modified system data by updating the real-time differential data received by the volatile memory unit 103 to a part of the system data to which the real-time differential data may belong. The part of the system data to which the real-time differential data is updated may be the modified system data. The identifying module 231 may identify the part of the system data to which the real-time differential data may belong, based on the one or more predefined policies that comprises the predefined classification of the system data.
As an example, consider that the real-time differential data belongs to the type of the system data related to the OS. Accordingly, the generating module 221 may generate the modified system data by updating the real-time differential data to the part of the system data related to the OS. Further, the transaction module 233 may identify one of the one or more predefined regions of the non-volatile memory unit 105, where the modified system data may be stored based on a start address and an end address where the real-time differential data is updated to the system data in the volatile memory unit 103, a base address of the system data in the volatile memory unit 103 and a size of the modified system data. As an example, consider the FIG.2E, that shows a page memory offset of the system data stored in the volatile memory unit 103. Consider that the real-time differential data is updated from the page memory offset 0x30000 to 0x34000 and size of the modified system data is 0x100 bytes. The base address of the system data in the volatile memory unit 103 may be 0x0. Therefore, based on this transaction data 213, the transaction module 233 may identify that the modified system data belongs to region 3. Consider the system receives the second system command “Take Snapshot” as shown in the Table 247b in the FIG.2C. Therefore, the compressing module 223 may compress the system data along with the modified system data present in the volatile memory unit 103.
Further, the storing module 225 may store the compressed system data and the compressed modified system data to a corresponding one of the one or more predefined regions based on the predefined classification. Therefore, the compressed system data and the compressed modified system data may be stored in the single pages having the Page IDs “0” to “4” as shown in the Table 247c in the FIG.2C in the corresponding one of the one or more predefined regions based on the predefined classification. Further, the region header associated with each of the one or more predefined regions is updated to indicate Page ID, Region ID and region-page map as shown in the Table 249b in the FIG.2D. As an example, the system data and the modified system data belonging to region ID “0” (region 0) are placed in the single page having the Page ID “0”. Similarly, the system data and the modified system data belonging to region ID “1” (region 1) are placed in the single page having the Page ID “1”. The entry “FF” or in other words “Invalid” in the region header indicates that a first-time storage of the system data and the modified system data belonging to a specific predefined region has not occurred in the non-volatile memory unit 105. As an example, the system data and the modified system data belonging to the region ID “1” (region 1) is being placed in the non-volatile memory unit 105 for the first time. Therefore, the single page having the Page ID “1” had the entry “FF” when the system data and the modified system data belonging to region 0 was being stored. Upon completing the first-time storage, the entry “FF” is replaced by the region ID “1” indicating that the Page 1 comprises the system data and the modified system data belonging to the region 1.
In the next iteration, consider that the transaction module 233 identifies that the modified system data belongs to region 2. Further, consider that the system receives the first system command “Log Commits” as shown in the Table 247b in the FIG.2C. Therefore, the compressing module 223 may compress the modified system data belonging only to region 2 into a single page and the storing module 225 may store the compressed modified system data in the single page of the non-volatile memory unit 105, having the Page ID “5” as shown in the Table 247c in the FIG.2C. Further, the processor 109 may update the region header as shown in the Table 249b in the FIG.2D, to indicate the real-time position of the compressed modified system data stored in the non-volatile memory unit 105. As an example, the modified system data belonging to the region ID “2” (region 2) is stored in the single page having the Page ID “5”. Therefore, the previous entry of Page ID “2” is replaced by Page ID “5” in the region header under the region ID “2” to indicate that, the single page having the Page ID “5” of the non-volatile memory unit 105 comprises a latest update of the system data belonging to region 2 i.e. Page ID “5” is the last updated page of the region 2.
In the next iteration, consider that the transaction module 233 identifies that the modified system data belongs to region 2 and region 3 i.e. part of the modified system data belongs to region 2 and rest of the modified system data belongs to region 3. Further, consider that the system receives the first system command “Log Commits” as shown in the Table 247b in the FIG.2C. Therefore, the compressing module 223 may compress the modified system data belonging only to region 2 and region 3 into a single page individually. Further, the storing module 225 may store the compressed modified system data belonging to region 2 in the single page of the non-volatile memory unit 105, having the Page ID “8” and the compressed modified system data belonging to region 3 in the single page of the non-volatile memory unit 105, having the Page ID “9” one after the other, as shown in the Table 247c in the FIG.2C. Furthermore, the processor 109 may update the region header as explained for the above iterations to indicate the real-time position of the compressed modified system data stored in the non-volatile memory unit 105.
The above-mentioned method of generating the modified system data, compressing the modified system data and storing the compressed modified system data of the size 16KB in the single pages belonging to the one or more predefined regions of the non-volatile memory unit 105 may be performed iteratively until the processor 109 receives the system boot request from the one or more system boot modules. Upon receiving the system boot request, the system boot module 227 may read the last updated page comprising the compressed modified system data from each of the one or more predefined regions in the non-volatile memory unit 105. In some embodiments, only the last updated page is read from each of the one or more predefined regions because the last updated page of each of the one or more predefined regions may include latest version of the corresponding system data stored in the form of compressed modified system data in each of the one or more predefined regions. Consider, the processor 109 receives the system boot request upon updating the Page 10 in the non-volatile memory unit 105. Therefore, as shown in the Table 249b in the FIG.2D, the last updated page of, the region 0 is Page 0, the region 1 is Page 9, the region 2 is Page 7, the region 3 is Page 10 and the region 4 is Page 4. Therefore, the system boot module 227 may read the single pages having the Page ID “0”, “9”, “7”, “10” and “4” from the predefined regions “0”, “1”, “2”, “3” and “4” respectively from the non-volatile memory unit 105 to the volatile memory unit 103. Upon reading the single pages, the decompressing module 229 may decompress the compressed modified system data present in each single page to obtain the latest version of the system data for booting the system.
Upon booting the system, the system boot module 227 may compute the time taken for booting the system using the below given Equation 2.
Time taken for booting the system = (RT1 + RT2 + RT3) -------------- Equation 2
Consider that the time required (RT1) for identifying the last updated page from each of the one or more predefined regions in the non-volatile memory unit 105 is 700 microseconds (us). Consider that the system boot module 227 may read 4 pages parallelly in the non-volatile memory unit 105. Therefore, the system boot module 227 may require 2 read operations for reading 5 pages in the non-volatile memory unit 105. Further, consider that the system boot module 227 may take 100us for performing a single read operation from the non-volatile memory unit 105. Therefore, the total time taken (RT2) for reading 5 single pages from 5 regions of the non-volatile memory unit 105 may be: RT2 = 100us * 2 read operations = 200us. Further, consider that the system boot module 227 may take 50us to decompress a single page comprising the compressed modified system data. Therefore, the time taken to decompress 5 single pages read from 5 regions of the non-volatile memory unit 105 may be: RT3 = 50us * 5 = 250us. However, the decompressing module 229 may parallelly decompress the compressed modified system data belonging to one single page while the other single page is being read from the non-volatile memory unit 105 to the volatile memory unit 103. Therefore, the time taken to decompress 5 single pages in the volatile memory unit 103 would be optimized to 250/2 = 125us.
Therefore, by substituting the values of RT1, RT2 and RT3 in the Equation 2, the total time taken for booting the system is 700us + 200us + 125us = 1025us
Therefore, the total time taken for booting the system is 1025us or 1.03ms. This is an optimized system boot time, that would remain constant for every system boot, unlike the existing art that provides a varying system boot time for every system boot.
FIG.3A illustrates a flowchart showing method of managing system data for optimizing boot time of a system whose system data may be compressed to a single page, in accordance with some embodiments of the present disclosure.
As illustrated in FIG.3A, the method 300a comprises one or more blocks illustrating method of managing system data for optimizing boot time of a system. The method 300a may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform particular functions or implement particular abstract data types.

The order in which the method 300a is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 300a. Additionally, individual blocks may be deleted from the method 300a without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 300a can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block 301, a processor 109 of the memory management system 107 may generate a modified system data by updating a real-time differential data, to a system data stored in a volatile memory unit 103 associated with the memory management system 107. In some embodiments, the system data may be data required for a system boot.
At block 303, the processor 109 may compress the modified system data upon receiving one or more system commands. As an example, the one or more system commands may include, but not limited to, “Take Snapshot” and “Commit Logs”. The system command “Take Snapshot” may require storing the complete compressed modified system data in the non-volatile memory unit 105, whereas the system command “Commit Logs” may require storing only modified part of the system data in the non-volatile memory unit 105.
At block 305, the processor 109 may store the compressed modified system data in a single page of a non-volatile memory unit 105 associated with the memory management system 107. In some embodiments, the single page is a first available empty page in the non-volatile memory unit 105. Further, size of the compressed modified system data stored in the single page of the non-volatile memory unit 105 may be less than or equal to page size in the non-volatile memory unit 105.
At block 307, the processor 109 may read the single page from the non-volatile memory unit 105 to the volatile memory unit 103, upon receiving a system boot request from one or more system boot modules associated with the memory management system 107, thereby optimizing the boot time of the system. In some embodiments, the single page read from the non-volatile memory unit 105 may be a last updated page comprising the compressed modified system data. Upon reading the single page, the processor 109 may decompress the compressed modified system data present in the single page for booting the system. The processor 109 may read and decompress only the single page i.e. the last updated page for every system boot request, thus optimizing and maintaining constant boot time of the system.
FIG.3B illustrates a flowchart showing method of managing system data for optimizing boot time of a system whose system data may be compressed to more than a single page, in accordance with some embodiments of the present disclosure.
As illustrated in FIG.3B, the method 300b comprises one or more blocks illustrating method of managing system data for optimizing boot time of a system. The method 300b may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform particular functions or implement particular abstract data types.

The order in which the method 300b is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 300b. Additionally, individual blocks may be deleted from the method 300b without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 300b can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block 309, a processor 109 of the memory management system 107 may identify one of one or more predefined regions configured in a non-volatile memory unit 105 associated with the memory management system 107 to be used for storing a modified system data. In some embodiments, the modified system data is generated by updating a real-time differential data to a corresponding part of the system data in a volatile memory unit 103 associated with the memory management system 107.

At block 311, the processor 109 may compress the modified system data upon receiving a first predefined system command. As an example, the first system command may include, but not limited to, “Commit Logs”, that may require storing only the modified system data in the non-volatile memory unit 105. In some embodiments, size of the compressed modified system data corresponding to the one of the one or more predefined regions is less than or equal to page size in the non-volatile memory unit 105.

At block 313, the processor 109 may store the compressed modified system data in a single page belonging to the one of the one or more predefined regions in the non-volatile memory unit 105. Further, the processor 109 may update a region header associated with each of the one or more predefined regions. In some embodiments, the region header comprises information related to page Identifier (ID), region ID and a region-page map data that indicates real-time position of the compressed modified system data in the non-volatile memory unit 105.
At block 315, the processor 109 may read the single page from the one of the one or more predefined regions and a last updated page from each of rest of the one or more predefined regions from the non-volatile memory unit 105 to the volatile memory unit 103, upon receiving a system boot request from one or more system boot modules associated with the memory management system 107, thereby optimizing the boot time of the system. In some embodiments, the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions are identified based on the region header associated with each of the one or more predefined regions. Further, the processor 109 may decompress the compressed modified system data present in the single page read from the one of the one or more predefined regions and the last updated page read from each of the rest of the one or more predefined regions, in the volatile memory unit 103 for booting the system. The processor 109 may read and decompress only the single page i.e. the last updated page from each of the one or more predefined regions for every system boot request, thus optimizing and maintaining constant boot time of the system. In some embodiments, when the processor 109 may receive a second predefined system command “Take Snapshot” instead of the first predefined system command, the processor 109 may compress the system data along with the modified system data present in the volatile memory unit 103 and further store in respective one or more predefined regions in the non-volatile memory unit 105.
FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.
In an embodiment, FIG.4 illustrates a block diagram of an exemplary computer system 400 for implementing embodiments consistent with the present invention. In an embodiment, the computer system 400 can be memory management system 107 that is used for managing system data for optimizing boot time of a system. The computer system 400 may include a central processing unit (“CPU” or “processor”) 402. The processor 402 may include at least one data processor for executing program components for executing user or system-generated business processes. A user may include a person, a person using a device such as such as those included in this invention, or such a device itself. The processor 402 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.
The processor 402 may be disposed in communication with one or more input/output (I/O) devices (411 and 412) via I/O interface 401. The I/O interface 401 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like), etc.
Using the I/O interface 401, computer system 400 may communicate with one or more I/O devices (411 and 412).
In some embodiments, the processor 402 may be disposed in communication with a communication network 409 via a network interface 403. The network interface 403 may communicate with the communication network 409. The network interface 403 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 403 and the communication network 409, the computer system 400 may communicate with a volatile memory unit 413 and a non-volatile memory unit 415. The communication network 409 can be implemented as one of the different types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 409 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 409 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. As an example, the volatile memory unit 413 may be a Random-Access Memory (RAM), a Dynamic RAM (DRAM), a Synchronous DRAM (SDRAM) and the like. As an example, the non-volatile memory unit 415 may be a Solid-State Device (SSD), a Hard Disk Drive (HDD), floppy disks, optical disks and the like. In some embodiments, the processor 402 may be disposed in communication with a memory 405 (e.g., RAM, ROM, etc. not shown in FIG.4) via a storage interface 404. The storage interface 404 may connect to memory 405 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fibre channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.
The memory 405 may store a collection of program or database components, including, without limitation, a user interface 406, an operating system 407, a web browser 408 etc. In some embodiments, the computer system 400 may store user/application data, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase.
The operating system 407 may facilitate resource management and operation of the computer system 400. Examples of operating systems include, without limitation, Apple Macintosh OS X, UNIX, Unix-like system distributions (e.g., Berkeley Software Distribution (BSD), FreeBSD, NetBSD, OpenBSD, etc.), Linux distributions (e.g., Red Hat, Ubuntu, Kubuntu, etc.), International Business Machines (IBM) OS/2, Microsoft Windows (XP, Vista/7/8, etc.), Apple iOS, Google Android, Blackberry Operating System (OS), or the like. The User interface 406 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 400, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical User Interfaces (GUIs) may be employed, including, without limitation, Apple Macintosh operating systems’ Aqua, IBM OS/2, Microsoft Windows (e.g., Aero, Metro, etc.), Unix X-Windows, web interface libraries (e.g., ActiveX, Java, Javascript, AJAX, HTML, Adobe Flash, etc.), or the like.
In some embodiments, the computer system 400 may implement the web browser 408 stored program components. The web browser 408 may be a hypertext viewing application, such as Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, Apple Safari, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS) secure sockets layer (SSL), Transport Layer Security (TLS), etc. Web browsers may utilize facilities such as AJAX, DHTML, Adobe Flash, JavaScript, Java, Application Programming Interfaces (APIs), etc. In some embodiments, the computer system 400 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as Active Server Pages (ASP), ActiveX, American National Standards Institute (ANSI) C++/C#, Microsoft .NET, CGI scripts, Java, JavaScript, PERL, PHP, Python, WebObjects, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), Microsoft Exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 400 may implement a mail client stored program component. The mail client may be a mail viewing application, such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Mozilla Thunderbird, etc.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, non-volatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.
Advantages of the embodiment of the present disclosure are illustrated herein.

In an embodiment, the present disclosure provides a method and a system for managing system data for optimizing boot time of a system.

The present disclosure provides a feature wherein the real-time differential data is directly updated to the system data in the volatile memory unit, instead of accumulating the real-time differential data as various logs over a period of time.

The present disclosure provides a feature wherein the system data or a modified system data is stored in the non-volatile memory unit in a compressed format, thus reducing amount of memory space used in the non-volatile memory unit for storing the system data or the modified system data in every iteration.

The present disclosure achieves a constant system boot time for booting the system by providing a feature wherein the modified system data i.e. latest update of the system data is compressed into a single page and stored in the non-volatile memory unit. Therefore, when the system receives a system boot request, the memory management system reads only the single page and decompresses contents of the single page in the volatile memory unit for booting the system. Since, only a single page is read in every iteration upon receiving the system boot request, the method achieves a constant system boot time for booting the system.

The present disclosure provides a feature wherein the system data can be stored in one or more predefined regions of the non-volatile memory unit when the system data cannot be compressed into a single page.

In the scenario where the non-volatile memory unit is configured with one or more predefined regions, the real-time differential data may be updated to only a corresponding part of the system data and stored in the corresponding predefined region of non-volatile memory unit, instead of storing the entire system data along with the modified system data.

The present disclosure provides a feature wherein a single page comprising the latest update of the system data is read from each of the one or more predefined regions for every iteration of the system boot. Therefore, the method achieves a constant system boot time for booting the system.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.

When a single device or article is described herein, it will be readily apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.

The specification has described a method and a system for managing system data for optimizing boot time of a system. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that on-going technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.

Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Referral numerals

Reference Number Description
100 Architecture
103 Volatile memory unit
105 Non-volatile memory unit
107 Memory management system
109 Processor
111 I/O interface
113 Memory
203 Data
205 Modules
211 Policy data
213 Transaction data
215 Other data
221 Generating module
223 Compressing module
225 Storing module
227 System boot module
229 Decompressing module
231 Identifying module
233 Transaction module
235 Other modules
400 Exemplary computer system
401 I/O Interface of the exemplary computer system
402 Processor of the exemplary computer system
403 Network interface
404 Storage interface
405 Memory of the exemplary computer system
406 User interface
407 Operating system
408 Web browser
409 Communication network
411 Input devices
412 Output devices
413 Volatile memory unit of the exemplary computing system
415 Non-volatile memory unit of the exemplary computing system