Some implementations include a method of managing a hosted non-volatile random-access memory (NVRAM) based storage subsystem that includes NVRAM devices. The method includes: receiving, at a device driver on the host computing device, write requests each requesting to write a respective unit of data to the NVRAM-based storage subsystem; categorizing the write requests into subgroups of write requests, where write requests within respective subgroups are mutually exclusive; ascertaining a load condition of each of several of the NVRAM devices of the NVRAM-based storage subsystem; identifying a target location on at least one NVRAM device to service a particular subgroup of write requests according to the ascertained load conditions of the NVRAM devices of the NVRAM-based storage subsystem; and servicing the particular subgroup of write requests by writing the corresponding units of data to the identified target location on the at least one NVRAM device of the NVRAM-based storage subsystem.
Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method of managing a hosted non-volatile random-access memory (NVRAM) storage subsystem that includes NVRAM devices, the method comprising: in response to receiving, at a device driver on the host computing device, a plurality of write requests each requesting to write a respective unit of data to the NVRAM-based storage subsystem, identifying each application process or thread that has issued a particular write request; based on results of the identification, classifying each write request into either a first subgroup of write requests or a second subgroup of write requests in which a smaller amount of data is being accessed by the first subgroup of write requests as issued from the corresponding application process or thread than the second subgroup of write requests as issued from the corresponding application process or thread; and identifying target locations on at least one NVRAM device of the NVRAM-based storage subsystem such that the first subgroup of write requests and the second subgroup of write requests are serviced at different target locations on the at least one NVRAM device, the NVRAM-based storage subsystem in communication with an intermediate volatile storage.
A method for managing an NVRAM storage system involves, upon receiving write requests, identifying the application process or thread that initiated each request. Based on this identification, write requests are classified into two subgroups. The first subgroup accesses a smaller amount of data per application process/thread compared to the second subgroup. The system then identifies different target locations on the NVRAM devices for servicing these subgroups, ensuring they are written to separate areas. The NVRAM system communicates with an intermediate volatile storage (like DRAM) for buffering.
2. The method of claim 1 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is latency-sensitive, and wherein a write request is latency-sensitive when the write request is to be serviced upon receipt with substantially zero delay.
The method described above classifies write requests by determining if a request is "latency-sensitive," meaning it needs to be serviced immediately upon receipt with almost no delay. This determination is part of the process of classifying each write request into either the first subgroup or the second subgroup based on the amount of data being accessed by each application process/thread. These latency-sensitive write requests are then treated differently with respect to target location.
3. The method of claim 2 , wherein determining whether a particular write request of the plurality of write requests is latency-sensitive comprises determining whether the write request is to be serviced as soon as possible upon receipt.
Determining if a write request is "latency-sensitive," as described above, includes checking if the write request should be serviced as quickly as possible after being received. This fast service requirement indicates that it belongs to the latency-sensitive subgroup of write requests. This is one criterion used to decide which subgroup a request should belong to.
4. The method of claim 2 , wherein determining whether a particular write request of the plurality of write requests is latency-sensitive comprises determining whether the write request is to be serviced with a higher priority than write requests determined as not latency-sensitive.
Determining if a write request is "latency-sensitive," as described above, includes checking if the write request has a higher priority compared to write requests that are not considered latency-sensitive. If it has higher priority, it is categorized as latency-sensitive. The priority determination is used in classifying write requests into the two subgroups.
5. The method of claim 2 , wherein determining whether a particular written request of the plurality of write request is latency-sensitive comprises determining whether the write request is to be serviced at the next available time instant.
Determining if a write request is "latency-sensitive," as described above, involves verifying if the write request is to be serviced at the next available time slot or processing cycle. Immediate availability for writing data is a criterion for assigning it to the latency-sensitive subgroup.
6. The method of claim 2 , wherein determining whether the particular write requests is latency sensitive further comprises: ascertaining a block size of the respective unit of data to be written per the particular write request; and identifying an application process or thread that has issued the write request.
Determining if a write request is latency-sensitive, in addition to the previous latency-sensitive criteria, includes: finding out the block size (amount of data) of the unit of data to be written and identifying the specific application process or thread that initiated the write request. This block size and process/thread information are used to categorize the request beyond just immediate service.
7. The method of claim 2 , further comprising: based on determining that the particular write request is latency-sensitive, scheduling the particular write request as an asynchronous write to the NVRAM-based storage subsystem, wherein the asynchronous write is carried out by sending the respective unit of data to the intermediate volatile storage and without confirming that the respective unit of data of the write request has been completely written to the target location on the at least one NVRAM device of the NVRAM-based storage subsystem.
If a write request is determined to be latency-sensitive, as described above, it is scheduled as an asynchronous write to the NVRAM system. This means the data is sent to the intermediate volatile storage (like DRAM), but the system *doesn't* wait for confirmation that the data has actually been written to the final target location on the NVRAM device. The lack of confirmation speeds up operation.
8. The method of claim 1 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is throughput-sensitive, and wherein a write request is throughput sensitive when the respective unit of data is to be written to a corresponding target location on a NVRAM device of the NVRAM-based storage subsystem while bypassing the intermediate storage in communication with the NVRAM-based storage subsystem.
The method classifies write requests by determining if a request is "throughput-sensitive," meaning the data should be written directly to the NVRAM device, bypassing the intermediate volatile storage (like DRAM) entirely. Direct writing enhances throughput and differs from latency-sensitive processing. The bypassing of intermediate storage defines throughput sensitivity.
9. The method of claim 8 , wherein determining whether the particular write request is throughput sensitive further comprises: ascertaining a block size of the respective unit of data to be written per the particular write request; and identifying an application process or thread that has issued the write request.
Determining if a write request is throughput-sensitive, in addition to the throughput-sensitive criteria above, includes: finding out the block size (amount of data) of the unit to be written and identifying the specific application process or thread that issued the write request. These additional details help refine how throughput-sensitive requests are handled.
10. The method of claim 8 , further comprising: based on determining that the particular write request is throughput-sensitive, scheduling the particular write request as a synchronous write to the NVRAM-based storage subsystem, wherein the synchronous write is performed by blocking an application process or thread on a computing device hosting the NVRAM-based storage subsystem that has issued the particular write request until the respective unit of data has been completely written to the at least one NVRAM device of the NVRAM-based storage subsystem.
If a write request is determined to be throughput-sensitive, as described above, it's scheduled as a synchronous write to the NVRAM system. This means the application process or thread that issued the write request is *blocked* (paused) until the data has been completely written to the NVRAM device. This blocking ensures data integrity but sacrifices speed for that particular process.
11. The method of claim 1 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is latency-sensitive or throughput-sensitive; wherein a subgroup of write requests categorized as latency-sensitive comprises write requests issued by a first set of application processes or threads on the host computing device, wherein a subgroup of write requests categorized as throughput-sensitive comprises write requests issued by a second set of application processes or threads on the host computing device, and wherein the first set of application processes or threads are smaller in size than the second set of application processes or threads.
The method classifies write requests into latency-sensitive or throughput-sensitive subgroups based on the application/thread issuing the request. Latency-sensitive requests come from a smaller set of applications/threads, while throughput-sensitive requests come from a larger set. The application/thread set size influences the classification and how requests are handled differently.
12. The method of claim 1 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is latency-sensitive or throughput-sensitive, wherein a subgroup of write requests categorized as latency-sensitive comprises write requests issued by a first set of application processes or threads on the host computing device, wherein a subgroup of write requests categorized as throughput-sensitive comprises write requests issued by a second set of application processes or threads on the host computing device, and wherein the second set of application processes or threads generate substantially more counts of write requests than the first set of application processes or threads.
The method classifies write requests into latency-sensitive or throughput-sensitive subgroups based on the application/thread issuing the request. Latency-sensitive requests come from applications/threads generating fewer write requests, while throughput-sensitive requests come from applications/threads generating significantly more write requests. The frequency of write requests determines the classification.
13. A system comprising a non-volatile random-access memory (NVRAM) based storage subsystem, the NVRAM-based storage subsystem comprising at least one NVRAM device in communication with a host computing device, the NVRAM-based storage subsystem is configured to perform the operations of: in response to receiving, at a device driver on the host computing device, a plurality of write requests each requesting to write a respective unit of data to the NVRAM-based storage subsystem, identifying each application process or thread that has issued a particular write request; based on results of the identification, classifying each write request into either a first subgroup of write requests or a second subgroup of write requests in which a smaller amount of data is being accessed by the first subgroup of write requests as issued from the corresponding application process or thread than the second subgroup of write requests as issued from the corresponding application process or thread; and identifying target locations on at least one NVRAM device of the NVRAM-based storage subsystem such that the first subgroup of write requests and the second subgroup of write requests are serviced at different target locations on the at least one NVRAM device, the NVRAM-based storage subsystem in communication with an intermediate volatile storage.
An NVRAM-based storage system connected to a host computer classifies incoming write requests based on their originating application process or thread. If a smaller amount of data is being accessed by the application process/thread, the write request is classified into a first subgroup; otherwise, it's classified into a second subgroup. The system directs these subgroups to different physical locations on the NVRAM device(s), leveraging an intermediate volatile storage (like DRAM).
14. The system of claim 13 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is latency-sensitive, and wherein a write request is latency-sensitive when the write request is to be serviced upon receipt with substantially zero delay.
The system above classifies write requests by determining if a request is "latency-sensitive," meaning it must be serviced immediately upon receipt with practically no delay. This immediacy test determines assignment to the first or second subgroup, impacting which physical location the data is written to on the NVRAM device.
15. The system of claim 14 , wherein determining whether a particular write request of the plurality of write requests is latency-sensitive comprises determining whether the write request is to be serviced as soon as possible upon receipt.
Determining if a write request is "latency-sensitive," as described in the system above, involves checking if the write request needs to be serviced as quickly as possible upon receipt. This requirement of immediate service qualifies a request as latency-sensitive.
16. The system of claim 14 , wherein determining whether a particular write request of the plurality of write requests is latency-sensitive comprises determining whether the write request is to be serviced with a higher priority than write requests determined as not latency-sensitive.
Determining if a write request is "latency-sensitive," as described in the system above, involves checking if the write request has a higher priority than other, non-latency-sensitive write requests. Higher priority implies latency sensitivity.
17. The system of claim 14 , wherein determining whether a particular written request of the plurality of write request is latency-sensitive comprises determining whether the write request is to be serviced at the next available time instant.
Determining if a write request is "latency-sensitive," as described in the system above, involves checking if the write request should be serviced at the next available time instant or processing cycle.
18. The system of claim 14 , wherein determining whether the particular write requests is latency sensitive further comprises: ascertaining a block size of the respective unit of data to be written per the particular write request; and identifying an application process or thread that has issued the write request.
Determining if a write request is latency-sensitive, as described in the system above, includes: finding out the block size (amount of data) of the data to be written and identifying the application process/thread that initiated the request. This information, combined with latency sensitivity, influences the data's destination on the NVRAM.
19. The system of claim 18 , wherein the operations further comprise: based on determining that the particular write request is throughput-sensitive, scheduling the particular write request as a synchronous write to the NVRAM-based storage subsystem, wherein the synchronous write is performed by blocking an application process or thread on a computing device hosting the NVRAM-based storage subsystem that has issued the particular write request until the respective unit of data has been completely written to the at least one NVRAM device of the NVRAM-based storage subsystem.
In the system above, if a write request is determined to be throughput-sensitive, it's scheduled as a synchronous write. This means the application/thread that sent the write request is paused until the data is completely written to the NVRAM device. This blocking behavior prioritizes data integrity over speed for that particular process/thread.
20. The system of claim 14 , wherein the operations further comprise: based on determining that the particular write request is latency-sensitive, scheduling the particular write request as an asynchronous write to the NVRAM-based storage subsystem, wherein the asynchronous write is carried out by sending the respective unit of data to the intermediate volatile storage and without confirming that the respective unit of data of the write request has been completely written to the target location on the at least one NVRAM device of the NVRAM-based storage subsystem.
In the system above, if a write request is determined to be latency-sensitive, it is scheduled as an asynchronous write to the NVRAM system. This means the data is sent to the intermediate volatile storage (like DRAM), but the system *doesn't* wait for confirmation that the data has been actually written to the NVRAM device.
21. The system of claim 13 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is throughput-sensitive, and wherein a write request is throughput sensitive when the respective unit of data is to be written to a corresponding target location on a NVRAM device of the NVRAM-based storage subsystem while bypassing the intermediate storage in communication with the NVRAM-based storage sub system.
The system described above classifies write requests by determining if a request is "throughput-sensitive." If so, the data is written directly to the NVRAM device, bypassing the intermediate volatile storage. This direct write maximizes throughput, as opposed to latency-sensitive writes that may use the intermediate storage.
22. The system of claim 21 , wherein determining whether the particular write request is throughput sensitive further comprises: ascertaining a block size of the respective unit of data to be written per the particular write request; and identifying an application process or thread that has issued the write request.
Determining if a write request is throughput-sensitive, as described in the system above, includes: finding out the block size (amount of data) of the unit to be written and identifying the specific application process or thread that issued the write request.
23. The system of claim 13 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is latency-sensitive or throughput-sensitive, wherein a subgroup of write requests categorized as latency-sensitive comprises write requests issued by a first set of application processes or threads on the host computing device, wherein a subgroup of write requests categorized as throughput-sensitive comprises write requests issued by a second set of application processes or threads on the host computing device, and wherein the first set of application processes or threads are smaller in size than the second set of application processes or threads.
The system above classifies write requests as either latency-sensitive or throughput-sensitive based on the application/thread that initiated the request. Latency-sensitive requests originate from a smaller set of applications/threads, while throughput-sensitive requests originate from a larger set. The size of the application set is a key differentiator.
24. The system of claim 13 , wherein classifying each write request into either a first subgroup of write requests or a second subgroup of write requests comprises determining whether a particular write request of the plurality of write requests is latency-sensitive or throughput-sensitive, wherein a subgroup of write requests categorized as latency-sensitive comprises write requests issued by a first set of application processes or threads on the host computing device, wherein a subgroup of write requests categorized as throughput-sensitive comprises write requests issued by a second set of application processes or threads on the host computing device, and wherein the second set of application processes or threads generate substantially more counts of write requests than the first set of application processes or threads.
The system above classifies write requests as either latency-sensitive or throughput-sensitive, based on the application/thread making the request. Latency-sensitive requests come from applications/threads generating fewer write requests. Throughput-sensitive requests come from applications/threads generating significantly more write requests.
25. A non-transitory computer readable medium, comprising software instructions, which software instructions when executed causes a non-volatile random-access memory (NVRAM) based storage subsystem, which NVRAM based storage subsystem comprising at least one NVRAM device in communication with a host computing device, to perform the operations of: in response to receiving, at a device driver on the host computing device, a plurality of write requests each requesting to write a respective unit of data to the NVRAM-based storage subsystem, identifying each application process or thread that has issued a particular write request; based on results of the identification, classifying each write request into either a first subgroup of write requests or a second subgroup of write requests in which a smaller amount of data is being accessed by the first subgroup of write requests as issued from the corresponding application process or thread than the second subgroup of write requests as issued from the corresponding application process or thread; and identifying target locations on at least one NVRAM device of the NVRAM-based storage subsystem such that the first subgroup of write requests and the second subgroup of write requests are serviced at different target locations on the at least one NVRAM device, the NVRAM-based storage subsystem in communication with an intermediate volatile storage.
A non-transitory computer-readable medium contains instructions that, when executed, cause an NVRAM storage system to: classify incoming write requests based on the application/thread they originate from. Write requests are classified into two groups based on the amount of data accessed; one group (first subgroup) containing requests from processes accessing less data than requests from processes in the second subgroup. Finally, the requests from each group are written to a different target location on the NVRAM device(s). The NVRAM system interacts with intermediate volatile storage.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
October 24, 2016
August 15, 2017
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.