A dormancy depth management method and ssd
By enabling SSDs to autonomously determine their sleep depth and utilizing a voting box and delivery counting mechanism, the problem of SSDs' inability to autonomously optimize power consumption is solved, achieving adaptive power optimization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HEFEI DATANG STORAGE TECH CO LTD
- Filing Date
- 2022-11-25
- Publication Date
- 2026-06-05
AI Technical Summary
In existing technologies, solid-state drives (SSDs) cannot optimize power consumption independently, rely on host driver features to configure power states, and cannot adaptively adjust hibernation depth according to actual conditions.
SSDs periodically determine their own sleep depth based on the sleep depth that their applications can enter. They use a voting box and delivery counting mechanism to determine whether each application can enter the current sleep depth and adaptively adjust the sleep depth to optimize power consumption.
It achieves autonomous power consumption optimization for SSDs by adaptively adjusting the sleep depth to reduce unnecessary power consumption and improve energy efficiency.
Smart Images
Figure CN115712395B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of power consumption control technology, and in particular to a hibernation depth management method and a solid state disk (SSD). Background Technology
[0002] In the existing technology, the Non-Volatile Memory Interface (NVME) protocol provides a complete set of power management negotiation mechanisms, and the host configures the power state of the SSD by setting features.
[0003] However, this approach relies on HOST driver features, and the SSD cannot automatically optimize power consumption. Summary of the Invention
[0004] This disclosure provides a hibernation depth management method and an SSD that enables the SSD to adaptively adjust its hibernation depth, thereby achieving autonomous power optimization.
[0005] On one hand, this disclosure provides a hibernation depth management method, including: a solid-state drive (SSD) periodically determining its own set hibernation depth based on the hibernation depth that its application functions can enter; wherein the set hibernation depth is the deepest hibernation depth that each application function in the SSD can enter.
[0006] On the other hand, this disclosure also provides an SSD, including a storage unit and a processing unit, wherein the storage unit is used to store an executable program;
[0007] The processing unit is used to read and execute the executable program to perform the following steps:
[0008] The hibernation depth set for the SSD is determined periodically based on the hibernation depth that the application functions in the SSD can enter; wherein, the set hibernation depth is the deepest hibernation depth that each application function in the SSD can enter.
[0009] Compared with related technologies, the sleep depth management method provided in this disclosure allows the SSD to periodically determine its own sleep depth based on the sleep depth that the application functions in it can enter. This enables the SSD to adaptively adjust its sleep depth, thereby achieving autonomous power consumption optimization.
[0010] Other features and advantages of this disclosure will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the disclosure. Other advantages of this disclosure may be realized and obtained by means of the methods described in the description and the accompanying drawings. Attached Figure Description
[0011] The accompanying drawings are used to provide an understanding of the technical solutions of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.
[0012] Figure 1 This is a flowchart illustrating a hibernation depth management method according to an embodiment of the present disclosure;
[0013] Figure 2 This is a flowchart illustrating another method for managing hibernation depth according to an embodiment of this disclosure;
[0014] Figure 3 This is a schematic diagram illustrating the relationship between voting, dormancy depth, and delivery count in an embodiment of this disclosure. Detailed Implementation
[0015] This disclosure describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.
[0016] This disclosure includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this disclosure may also be combined with any conventional features or elements to form a unique solution as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other solutions to form another unique solution as defined by the claims. Therefore, it should be understood that any feature shown and / or discussed in this disclosure may be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.
[0017] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that the method or process does not depend on the specific order of steps described herein. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims relating to the method and / or process should not be limited to the steps performed in the order written, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments disclosed herein.
[0018] This disclosure provides a method for managing hibernation depth, such as... Figure 1 As shown, it includes:
[0019] Step 101: The SSD periodically determines its own set hibernation depth based on the hibernation depth that the application functions in the SSD can enter; wherein, the set hibernation depth is the deepest hibernation depth that each application function in the SSD can enter.
[0020] For example, an SSD can independently perform many application functions, such as garbage collection, read and write, bad block management, and log management. Each application function knows which hibernation depth it cannot enter during its current running stage (entering such a depth would affect its own operation).
[0021] In related technologies, the host (where the SSD is plugged into the host via an interface) sets up a hibernation depth management method, and then manages the hibernation depth of the SSD according to the set method. However, the existing method is predetermined and cannot adjust the hibernation depth of the SSD in a timely and adaptive manner according to the actual situation of the SSD.
[0022] The sleep depth management method provided in this disclosure allows the SSD to periodically determine its own sleep depth based on the sleep depth that the application functions within it can enter. This enables the SSD to adaptively adjust its sleep depth, thereby achieving autonomous power consumption optimization.
[0023] In one exemplary instance, each hibernation depth corresponds to a configuration support range, and each application function determines whether it can enter various hibernation depths based on the configuration support it needs in the current execution phase.
[0024] For example, the various hibernation depths are pre-defined based on the SSD's power consumption and operating status. Assuming hibernation depth is represented by LPM, the various hibernation depths are LPM0, LPM1, and LPM2. LPM0 has the largest configuration support range; for example, it can be set to keep all resources and clocks active, resulting in maximum power consumption. LPM1 has a smaller configuration support range than LPM0; for example, it can be set to turn off some infrequently used peripherals, resulting in slightly lower power consumption. LPM2 has the smallest configuration support range; for example, it can be set to further turn off some infrequently used peripherals on top of LPM1, maintaining only the most basic peripherals, resulting in minimal functionality. Once the configuration support range for each hibernation depth is set, each application function knows the configuration support required for its current execution phase, i.e., which configuration support is needed, and thus knows which hibernation depths cannot be entered.
[0025] It should be noted that the configuration support required by each application may be different at different stages of execution. Therefore, the hibernation depth that the SSD determines as its own set hibernation depth refers to the hibernation depth that the application function can enter during the running stage when the periodic action is triggered in the SSD.
[0026] In one exemplary instance, the SSD periodically determines its own set hibernation depth based on the hibernation depth that its applications can enter, including:
[0027] The SSD periodically uses the shallowest hibernation depth as the current hibernation depth and performs the following judgment operation:
[0028] The SSD polls itself to see if each application function can enter the current sleep depth;
[0029] If each application function can enter the current hibernation depth, the SSD will take the hibernation depth one level deeper than the current hibernation depth as the new current hibernation depth and continue to perform the judgment operation until an application function cannot enter the current hibernation depth. In this case, the hibernation depth one level shallower than the current hibernation depth will be taken as the set hibernation depth; or until it is determined that all application functions can enter the deepest hibernation depth, the deepest hibernation depth will be taken as the set hibernation depth.
[0030] For example, during the process of performing a judgment operation on each level of hibernation depth, if it is determined that an application function cannot enter a certain level of hibernation depth, then the judgment is stopped, and no further judgment operation is performed on deeper levels of hibernation depth.
[0031] In one exemplary instance, the SSD polling itself to see if each application function can enter the current sleep depth includes:
[0032] The SSD determines whether each application function can enter the current hibernation depth by polling the votes in its pre-set voting box; wherein, all application functions correspond one-to-one with the votes in the voting box; each vote records information on whether the application function corresponding to this vote can enter various hibernation depths in the current execution phase.
[0033] For example, by using a combination of delivery voting and round-robin voting, SSDs can quickly determine whether each application function can enter various hibernation depths.
[0034] In one exemplary instance, each vote contains a stub for uniquely identifying the vote, each vote uniquely corresponds to an application function, and each application function includes at least one sub-function; each sub-function of each application function is delivered using the vote corresponding to its application function; each dormancy depth of each vote corresponds to a delivery count, and each delivery count is used to reflect whether the application function corresponding to the vote can enter the corresponding dormancy depth; initially, the value of each delivery count is 0;
[0035] The SSD determines whether each application function can enter the current hibernation depth by polling the votes in its pre-set voting box, including:
[0036] The SSD sequentially obtains the delivery count value corresponding to the current dormancy depth of each vote in the ballot box based on the ticket stub;
[0037] If the delivery count value corresponding to the current sleep depth of a vote is not 0, it is determined that there is an application function that cannot enter the current sleep depth.
[0038] When the delivery count corresponding to the current sleep depth of each vote is 0, it is determined that all application functions can enter the current sleep depth. The delivery count of each vote is calculated by the SSD during sub-function delivery based on the content of the vote, according to the rule that if the sub-function cannot enter the current sleep depth, the vote count corresponding to the current sleep depth of this vote is incremented by 1, and if the sub-function can enter the current sleep depth, the vote count corresponding to the current sleep depth of this vote is decremented by 1.
[0039] It should be noted that, since the ticket stub can uniquely identify a vote, each vote is matched one-to-one with an application function based on the ticket stub, thereby preventing different application functions from "getting" the same vote from the ballot box and ensuring the uniqueness of the vote.
[0040] For example, each application function is actually composed of a series of sub-functions, such as garbage collection, which includes temperature detection, etc. These sub-functions are essentially delivering votes. However, if each sub-function were assigned a separate vote, the number of votes would be large, making polling resource-intensive. Therefore, each application function is assigned a separate vote, and each sub-function can use the vote from its parent application function to deliver its vote. Each sub-function delivers a vote when its own sleep depth requirement changes, so the timing of each sub-function's vote delivery may differ. However, the SSD monitors this in real time. Once a sub-function delivers a vote, the SSD adjusts the delivery count value corresponding to the application function to which that sub-function belongs based on the information on the vote. The SSD doesn't need to store the specific content of the sub-function's vote; it only needs to modify the corresponding delivery count value based on the vote's content. During polling, the SSD only polls the delivery count value corresponding to each sleep depth on each vote. Based on the delivery count value, it can determine which application function can enter the corresponding sleep depth. Taking the target application function, the target delivery count value, and the target dormancy depth as examples, specifically, judging whether the target application function can enter the target dormancy depth by judging whether the target delivery count value is 0. A value of 0 means that either the sub-functions included in the target application function did not deliver a vote that prevents it from entering the target dormancy depth, or there was a sub-function that delivered a vote that prevented it from entering the target dormancy depth, but later delivered a vote that allowed it to enter the target dormancy depth. In this case, the delivery count value of the target dormancy depth is 0 (the initial state is 0). In both of these cases, the target delivery count value is 0 when counting, which means that the target application function can enter the target dormancy depth.
[0041] In one exemplary instance, the ballot box is represented by a two-dimensional array, the first dimension of which represents the ballot stub, the second dimension of which represents the dormancy depth, the elements in the two-dimensional array correspond one-to-one with the votes, and the value of each element in the two-dimensional array is used to indicate whether the sub-function that delivers the vote corresponding to that element can enter the current dormancy depth.
[0042] For example, the ballot box can be represented as a two-dimensional array, where each element of the array represents a vote. When polling for votes, the polling process actually polls this two-dimensional array, thus making the polling speed faster.
[0043] In one exemplary instance, the determination operation is performed on a multi-core processor.
[0044] For example, judgment operations with different sleep depths can be performed on different cores, thereby speeding up the execution process of the judgment operation.
[0045] This disclosure also provides a method for managing hibernation depth, such as... Figure 2 As shown, it includes:
[0046] Step 201: Creating the Ticket Box
[0047] Step 202: Obtaining Ticket Stubs
[0048] Step 203, Ballot Delivery
[0049] Step 204: Voting Decision
[0050] Specifically, during the SSD firmware SSD initialization phase, the ballot box is initialized. The ballot box is a two-dimensional array a[x][y]. x represents the ticket stub. y represents the dormancy depth, for example, LPM0, LPM1, LPM2, LPM3..., with corresponding ticket stubs a[x][0], a[x][1], a[x][2]... Each member of the array should at least contain a count (corresponding to the "delivery count" in the above embodiment) attribute, and may also include an Owner attribute. The Owner is used to record the current ticket stub acquisition function, and the count is used to record the number of vote deliveries. When a dormancy depth is disabled (corresponding to "cannot enter a certain dormancy depth" in the above embodiment), this count value is incremented by one; when the corresponding dormancy depth is enabled (corresponding to "can enter a certain dormancy depth" in the above embodiment), this count value is decremented by one. During initialization, the count of all ticket stubs in the ballot box is cleared to zero, and no function is acquired. At this time, the voting decision-making process will consider all ticket stubs invalid and default to entering the deepest dormancy depth.
[0051] During the initialization phase of each sub-function of the SSD, a ticket stub is obtained. This ticket stub can be either x in a[x][y] or the space address corresponding to a[x]. The firmware sub-functions need to record this ticket stub, and the information recorded in the ballot box will be updated based on the ticket stub during subsequent vote delivery and vote destruction to facilitate voting decisions.
[0052] During the SSD sub-function operation phase, based on the characteristics of each function and the length of the time window, a vote is submitted or a vote is destroyed to select the corresponding sleep depth for disabling or enabling. For example, if there are four sleep depths: LPM0, LPM1, LPM2, and LPM3, and the firmware operates two sub-functions, A and B, function A must have a sleep depth greater than or equal to LPM2 during operation; otherwise, it will affect the normal execution of function A. Function A can enter LPM3 when idle. Function B is a blocking operation, and different sleep depths are set by the size of the blocking time window. For example, according to calculations, when Tw>300s, allowing entry into LPM3 allows the device to reach the optimal power consumption value, and when Tw>100s, allowing entry into LPM2 allows the device to reach the optimal power consumption value.
[0053] The voting decision-making phase can poll and scan all votes in the vote bin on a single task (single-core) or a single CPU (multi-core). The scanning rule is from shallow to deep, starting from the shallowest sleep depth. When all votes have LPM0 voting results that allow entry, the current deepest sleep state is recorded as LPM0, and scanning continues to LPM1. If all votes have LPM1 voting results that allow entry, the current deepest sleep depth is updated to LPM1, and scanning proceeds to a deeper sleep depth. If any vote does not allow entry into the currently scanned sleep depth, the scan exits, and the system returns to the currently recorded allowed sleep depth. The sleep process is handled based on the sleep depth returned by the voting results, aiming to optimize power consumption to the maximum extent without affecting device usage.
[0054] A schematic diagram illustrating the correspondence between each vote in the ballot box, the various dormancy depth information on each vote, and the delivery count (referred to as "count" in this embodiment) of the various dormancy depth information on each vote can be shown as follows: Figure 3 As shown, Figure 3 As shown, the voting box contains vote 0, vote 1, and vote 2, and the dormancy depth includes LPM0, LPM1, and LPM2. For vote 0, LPM0 corresponds to one count, LPM1 corresponds to one count, and LPM2 corresponds to one count; for vote 1, LPM0 corresponds to one count, LPM1 corresponds to one count, and LPM2 corresponds to one count; for vote 2, LPM0 corresponds to one count, LPM1 corresponds to one count, and LPM2 corresponds to one count.
[0055] This disclosure also provides an SSD, including: a storage unit and a processing unit, wherein the storage unit is used to store an executable program;
[0056] The processing unit is used to read and execute the executable program to perform the following steps:
[0057] The hibernation depth set for the SSD is determined periodically based on the hibernation depth that the application functions in the SSD can enter; wherein, the set hibernation depth is the deepest hibernation depth that each application function in the SSD can enter.
[0058] The SSD provided in this embodiment periodically determines its own set sleep depth based on the sleep depth that the application functions in it can enter, thus enabling adaptive adjustment of the sleep depth and achieving autonomous optimization of power consumption.
[0059] In one exemplary instance, each hibernation depth corresponds to a configuration support range, and each application function determines whether it can enter various hibernation depths based on the configuration support it needs in the current execution phase.
[0060] In one exemplary instance, the processing unit is configured to read and execute the executable program to specifically implement the following steps:
[0061] Periodically use the shallowest hibernation depth as the current hibernation depth and perform the following judgment operation:
[0062] Poll to see if each application function in the SSD can enter the current hibernation depth;
[0063] If each application function can enter the current sleep depth, then the sleep depth one level deeper than the current sleep depth is taken as the new current sleep depth, and the judgment operation continues to be performed until an application function cannot enter the current sleep depth, then the sleep depth one level shallower than the current sleep depth is taken as the set sleep depth; or until it is determined that all application functions can enter the deepest sleep depth, then the deepest sleep depth is taken as the set sleep depth.
[0064] In one exemplary instance, the processing unit is configured to read and execute the executable program to specifically implement the following steps:
[0065] By polling the votes in the pre-set voting box of the SSD, it is determined whether each application function can enter the current hibernation depth; wherein, all application functions correspond one-to-one with the votes in the voting box; each vote records information on whether the application function corresponding to this vote can enter various hibernation depths in the current execution stage.
[0066] In one exemplary instance, each vote contains a stub for uniquely identifying the vote, each vote uniquely corresponds to an application function, and each application function includes at least one sub-function; each sub-function of each application function is delivered using the vote corresponding to its application function; each dormancy depth of each vote corresponds to a delivery count, and each delivery count is used to reflect whether the application function corresponding to the vote can enter the corresponding dormancy depth; initially, the value of each delivery count is 0.
[0067] In one exemplary instance, the processing unit is configured to read and execute the executable program to specifically implement the following steps:
[0068] Based on the ticket stubs, the delivery count value corresponding to the current dormancy depth of each vote in the ballot box is obtained sequentially;
[0069] If the delivery count value corresponding to the current sleep depth of a vote is not 0, it is determined that there is an application function that cannot enter the current sleep depth.
[0070] When the delivery count corresponding to the current sleep depth of each vote is 0, it is determined that all application functions can enter the current sleep depth. The delivery count of each vote is calculated by the SSD during sub-function delivery based on the content of the vote, according to the rule that if the sub-function cannot enter the current sleep depth, the vote count corresponding to the current sleep depth of this vote is incremented by 1, and if the sub-function can enter the current sleep depth, the vote count corresponding to the current sleep depth of this vote is decremented by 1.
[0071] In one exemplary instance, the ballot box is represented by a two-dimensional array, the first dimension of which represents the ballot stub, the second dimension of which represents the dormancy depth, the elements in the two-dimensional array correspond one-to-one with the votes, and the value of each element in the two-dimensional array is used to indicate whether the sub-function that delivers the vote corresponding to that element can enter the current dormancy depth.
[0072] In one exemplary instance, the determination operation is performed on a multi-core processor.
[0073] It should be understood that a processing unit can be a Central Processing Unit (CPU), or it can be other general-purpose processing units, digital signal processing units (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic units, discrete gate or transistor logic units, discrete hardware components, etc. A general-purpose processing unit can be a microprocessor unit or any conventional processing unit.
[0074] The storage unit may include read-only memory units and random access memory units, and provides instructions and data to the processing unit. A portion of the storage unit may also include non-volatile random access memory units. For example, the storage unit may also store information about the device type.
[0075] This application describes several embodiments, but these descriptions are exemplary and not restrictive, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.
[0076] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application may also be combined with any conventional features or elements to form a unique inventive scheme as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other inventive schemes to form another unique inventive scheme as defined by the claims. Therefore, it should be understood that any feature shown and / or discussed in this application may be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.
[0077] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.
Claims
1. A method for managing hibernation depth, characterized in that, include: The solid-state drive (SSD) periodically determines its own set hibernation depth based on the hibernation depth that the applications within it can enter. Each hibernation depth corresponds to a configuration support range, and each application function determines whether it can enter various hibernation depths based on the configuration support required at its current execution stage. The set hibernation depth is the deepest hibernation depth that each application function within the SSD can enter.
2. The method according to claim 1, characterized in that, The SSD periodically determines its own set hibernation depth based on the hibernation depth that its applications can enter, including: The SSD periodically uses the shallowest hibernation depth as the current hibernation depth and performs the following judgment operation: The SSD polls itself to see if each application function can enter the current sleep depth; If each application function can enter the current hibernation depth, the SSD will take the hibernation depth one level deeper than the current hibernation depth as the new current hibernation depth and continue to perform the judgment operation until an application function cannot enter the current hibernation depth. In this case, the hibernation depth one level shallower than the current hibernation depth will be taken as the set hibernation depth; or until it is determined that all application functions can enter the deepest hibernation depth, the deepest hibernation depth will be taken as the set hibernation depth.
3. The method according to claim 2, characterized in that, The SSD polls itself to check whether each application function can enter the current sleep depth, including: The SSD determines whether each application function can enter the current hibernation depth by polling the votes in its pre-set voting box; wherein, all application functions correspond one-to-one with the votes in the voting box; each vote records information on whether the application function corresponding to this vote can enter various hibernation depths in the current execution phase.
4. The method according to claim 3, characterized in that, Each vote contains a stub that uniquely identifies the vote. Each vote uniquely corresponds to an application function. Each application function includes at least one sub-function. Each sub-function of each application function is delivered using the vote corresponding to its application function. Each dormancy depth of each vote corresponds to a delivery count. Each delivery count is used to reflect whether the application function corresponding to the vote can enter the corresponding dormancy depth. Initially, the value of each delivery count is 0. The SSD determines whether each application function can enter the current hibernation depth by polling the votes in its pre-set voting box, including: The SSD sequentially obtains the delivery count value corresponding to the current dormancy depth of each vote in the ballot box based on the ticket stub; If the delivery count value corresponding to the current sleep depth of a vote is not 0, it is determined that there is an application function that cannot enter the current sleep depth. When the delivery count corresponding to the current sleep depth of each vote is 0, it is determined that all application functions can enter the current sleep depth. The delivery count of each vote is calculated by the SSD during sub-function delivery based on the content of the vote, according to the rule that if the sub-function cannot enter the current sleep depth, the vote count corresponding to the current sleep depth of this vote is incremented by 1, and if the sub-function can enter the current sleep depth, the vote count corresponding to the current sleep depth of this vote is decremented by 1.
5. The method according to claim 4, characterized in that, The ballot box is represented by a two-dimensional array. The first dimension of the two-dimensional array is used to represent the ballot stub, and the second dimension is used to represent the dormancy depth. Each element in the two-dimensional array corresponds to a ballot, and the value of each element in the two-dimensional array is used to indicate whether the sub-function that delivers the ballot corresponding to that element can enter the current dormancy depth.
6. The method according to claim 2, characterized in that, The judgment operation is performed on a multi-core processor.
7. An SSD, characterized in that, It includes a storage unit and a processing unit, wherein the storage unit is used to store the executable program; The processing unit is used to read and execute the executable program to perform the following steps: The hibernation depth set for the SSD is determined periodically based on the hibernation depth that the application functions in the SSD can enter; wherein, each hibernation depth corresponds to a configuration support range, and each application function determines whether it can enter various hibernation depths based on the configuration support it needs in the current execution stage; the set hibernation depth is the deepest hibernation depth that each application function in the SSD can enter.
8. The SSD according to claim 7, characterized in that, The processing unit is used to read and execute the executable program to specifically implement the following steps: Periodically use the shallowest hibernation depth as the current hibernation depth and perform the following judgment operation: Poll to see if each application function in the SSD can enter the current hibernation depth; If each application function can enter the current sleep depth, then the sleep depth one level deeper than the current sleep depth is taken as the new current sleep depth, and the judgment operation continues to be performed until an application function cannot enter the current sleep depth, then the sleep depth one level shallower than the current sleep depth is taken as the set sleep depth; or until it is determined that all application functions can enter the deepest sleep depth, then the deepest sleep depth is taken as the set sleep depth.