Device hibernation control

Devices, systems and methods are disclosed for limiting a number of hibernations based on a finite lifetime expectancy of nonvolatile memory. As the nonvolatile memory has a finite lifetime expectancy, a device may determine cumulative thresholds and associated session thresholds and may limit a frequency that the device hibernates. For example, the device may determine a cumulative number of hibernations and associate the cumulative number of hibernations with a cumulative threshold. The device may determine a session threshold corresponding to the cumulative threshold and may limit a number of hibernations using the session threshold. For example, the device may enter a hibernation state up to the session threshold and thereafter may enter a suspended state instead.

BACKGROUND

With the advancement of technology, the use and popularity of electronic devices has increased considerably. For mobile electronic devices, battery power may be conserved using a low power hibernation mode.

DETAILED DESCRIPTION

Electronic devices, such as electronic readers, commonly include a battery. To reduce power consumption and therefore increase a length of battery life, a device may enter a low power consumption state when the device idle. A first example of a low power consumption state is a suspended state, which reduces the power consumption a small amount but may resume normal operation relatively quickly as power is maintained to volatile memory (e.g., random-access memory (RAM) such as double data rate synchronous dynamic random-access memory (DDR SDRAM)) and therefore data stored in the volatile memory is refreshed. A second example of a low power consumption state is a hibernation state, which reduces the power consumption a large amount but may resume normal operation relatively slowly as power is not maintained to the volatile memory and therefore data stored in the volatile memory (e.g., snapshot data) must be loaded from nonvolatile memory (e.g., hard drive, solid state drive or the like such as an embedded multimedia card (eMMC)).

The time from receiving a restore command to system interactivity (e.g., device responding to user input) may be reduced by preloading a portion of the snapshot data from the nonvolatile memory to the volatile memory, resuming system interactivity and then loading the remaining snapshot data during idle periods. However, while the time to system interactivity is reduced, a user may perceive lag when snapshot data isn't loaded in the volatile memory and must be loaded from the nonvolatile memory. In addition, a sequential read/write speed associated with the preloading of the nonvolatile memory may be much faster than a random access read/write speed associated with loading the data on-demand.

To reduce power consumption while reducing a latency perceived by a user, devices, systems and methods are disclosed for determining data to include in snapshot data and preloading a portion of the snapshot data upon resuming from a hibernation state. By preloading snapshot data that is likely to be requested by the user, the device may reduce the perceived latency as the requested data is already loaded in the volatile memory.

FIG. 1Aillustrates an overview of a system100for implementing embodiments of the present disclosure. The system100includes a device102, such as a smart phone, an electronic reader or the like, having a display104. The display104may be an electrophoretic display, an electrowetting display and/or other low-power, high-latency displays known to one of skill in the art. However, the present disclosure is not limited thereto and the device102may be any electronic device including a processor and a battery.

To reduce power consumption and therefore increase a battery life of the device102, the device102may disable components and enter a low power consumption state. When the device102disables a component or disables power to the component, the device102is turning off, powering off or otherwise disabling the component so that the component does not consume power. While the component is disabled, the component is unable to perform normal operation and certain features of the device102are therefore unavailable. Thus, the device102may disable components to reduce the power consumption during periods of inactivity. Examples of a low power consumption state include a suspended state and/or a hibernation state. The suspended state has lower power consumption than normal system operation but maintains power to certain components and maintains data stored in volatile memory, allowing the device102to resume normal system operation (e.g., system interactivity) after a short period of time. In contrast, the hibernation state has even lower power consumption than the suspended state but resuming normal system operation (e.g., system interactivity) requires a slightly longer period of time. For example, the hibernation state reduces power consumption by copying a snapshot of data stored in the volatile memory into nonvolatile memory and disabling additional components, such as the volatile memory. In order to resume normal system operation, the device102must copy the snapshot from the nonvolatile memory back to the volatile memory prior to system interactivity (e.g., responsiveness to input from a user) corresponding to an active state. A period of time between exiting the hibernation state and entering the active state may be referred to as an “unresponsive state.” In the unresponsive state, the device102may display content on the display104and otherwise appear interactive, but the snapshot is being copied to the volatile memory and the device102is unresponsive to user input.

As illustrated inFIG. 1A, the device102may receive (120) a hibernation command instructing the device102to enter the hibernation state. In response to receiving the hibernation command, the device102may determine (122) a list of processes to be preloaded after hibernation, determine (124) preload data, store (126) the list and the preload data in a snapshot in nonvolatile memory and store (128) additional data in the snapshot. For example, as will be discussed in greater detail below, the device102may identify processes running (e.g., executing) on the device102, may determine first data associated with the running processes and may select a first portion of the first data as the preload data and a second portion of the first data as the additional data. After storing the snapshot, the device102may enter (130) the hibernation state and reduce the power consumption of the device102by removing power to components in the device102.

The device102may receive (132) a command to exit the hibernation state and resume normal system operation. For example, the command may be a wake-up event, a physical press of a power button or the like that triggers the device102to exit the hibernation state. To resume system operation, the device102may load (134) the preload data during preloading, may activate (136) user space processes and may resume (138) system operation. After resuming the system operation, the device102may be responsive to user input.

After resuming system operation, the device102may load (140) data from the snapshot during on-demand loading. For example, the user may input a command associated with a first process and the device102may load data associated with the first process from the snapshot. The device102may load (142) remaining data from the snapshot when the system is idle. For example, the device102may determine that the device102is idle and may load the remaining data until the system is no longer idle.

To improve battery life of the device102and reduce overall power consumption, the device102may enter the hibernation state when the device is idle. However, each time the device102enters the hibernation state the device102may store data from volatile memory to a snapshot in nonvolatile memory, such as solid state storage like embedded multimedia card (eMMC), that has a finite lifetime expectancy. For example, the nonvolatile memory may write to an individual sector a fixed number of times (e.g., 2,000 times) before receiving read/write errors associated with the sector, although each individual sector is different. To prolong a useful life of the nonvolatile memory, the nonvolatile memory may include a controller that performs wear leveling to evenly distribute read/write commands throughout the sectors. However, after entering the hibernation state a number of times, an amount of sectors receiving read/write errors rises above a threshold and the nonvolatile memory reaches its finite lifetime expectancy.

In order to prolong the useful life of the nonvolatile memory, and therefore reduce power consumption of the device102by enabling the device102to enter the hibernation state over a longer period of time, the device102may limit a frequency that the device102enters the hibernation state. For example, after a first number of “cumulative hibernations” (e.g., the device102enters the hibernation state a first number of times over a total lifetime of the device102), the device102may limit the device to a fixed number of “session hibernations” (e.g., the device102enters the hibernation state a maximum of the fixed number of times over a period of time).

As illustrated inFIG. 1B, the device102may determine (150) cumulative threshold(s) and determine (152) session threshold(s) that correspond to the cumulative threshold(s). The device102may receive (154) a hibernation command, determine (156) a first value of cumulative hibernations (e.g., total number of times that the device102entered the hibernation state over the total lifetime of the device102) and may determine (158) a session threshold corresponding to the first value. For example, the device102may compare the first value to one or more cumulative thresholds and may determine a corresponding session threshold (e.g., maximum number of times that the device102may enter the hibernation state for each session or interval). The device102may determine (160) a second value of session hibernations, may determine (162) that the second value is below the session threshold and may enter (164) the hibernation state.

The device102may compare the total number of hibernations to any number of cumulative thresholds. In some examples, the device102may include a cumulative counter that increments each time the device102enters the hibernation state, such that an output of the cumulative counter corresponds to the cumulative number of hibernations. Similarly, the device102may include a session counter that increments each time the device102enters the hibernation state and resets to zero at the end of the session, such that an output of the session counter corresponds to the number of hibernations per session.

The session threshold may correspond to fixed intervals of time (e.g., hourly, daily, weekly, etc.) and/or to variable intervals of time (e.g., each time the device102is on battery power, resetting when the device102is being charged or each time the device102is powered on, resetting when the device102is powered off). Thus, a number of times that the device102enters the hibernation state may vary over time and the device102may determine an interval associated with the session based on usage of the device102. For example, if the device102is charged once a week or less, the device102may associate the session threshold with a weekly interval, thus limiting the device102to hibernating a maximum number of times per week to reduce power consumption and prolong the battery life. In contrast, if the device102is charged twice a week or more, the device102may base the session threshold on the frequency of charging, thus limiting the device102to hibernating a maximum number of times each time that the device102runs on battery power. This may avoid a situation where a battery of the device102lasts a first duration early in the week (when the device102enters the hibernation state) and a second duration later in the week (when the device102has exceeded the session threshold and enters the suspended state instead, consuming more power).

To illustrate an example, the device102may determine a first cumulative threshold (e.g., 50% of lifetime expectancy) associated with a first session threshold (e.g., entering the hibernation state a maximum of 10 times per day) and a second cumulative threshold (e.g., 75% of lifetime expectancy) associated with a second session threshold (e.g., entering the hibernation state a maximum of 5 times per day). Thus, the device102may enter the hibernation state an unlimited amount of times per day until the total number of hibernations is above the first cumulative threshold (e.g., total number of hibernations >50% of lifetime expectancy), at which point the device102may enter the hibernation state up to the first session threshold (e.g., a maximum of 10 hibernations per day). Once the device102reaches the first session threshold (e.g., 10 hibernations in one day), the device102may enter a suspended state instead of the hibernation state until an expiration of the session (e.g., until the next day). After the total number of hibernations is above the second cumulative threshold (e.g., total number of hibernations >75% of lifetime expectancy), the device102may enter the hibernation state up to the second session threshold (e.g., a maximum of 5 hibernations per day). Once the device102reaches the second session threshold (e.g., 5 hibernations in one day), the device102may enter the suspended state instead of the hibernation state until an expiration of the session (e.g., until the next day).

As discussed above, the device102may reduce power consumption by disabling components and entering a suspended state and/or a hibernation state. The suspended state has lower power consumption than normal system operation but maintains power to certain components and maintains data stored in volatile memory, allowing the device102to resume normal system operation (e.g., system interactivity) after a short period of time. In contrast, the hibernation state has even lower power consumption than the suspended state but resuming normal system operation (e.g., system interactivity) requires a slightly longer period of time. For example, the hibernation state reduces power consumption by copying a snapshot of data stored in the volatile memory into nonvolatile memory and disabling additional components, such as the volatile memory. In order to resume normal system operation, the device102must copy the snapshot from the nonvolatile memory back to the volatile memory prior to system interactivity (e.g., responsiveness to input from a user).

FIG. 2Aillustrates a block diagram of the device in a suspended state200. As illustrated inFIG. 2A, the device102may include a Power Management Integrated Circuit (PMIC)202, an integrated circuit (IC)210, volatile memory222(e.g., random-access memory (RAM) such as double data rate synchronous dynamic random-access memory (DDR SDRAM)), nonvolatile memory224(e.g., hard drive, solid state drive or the like such as an embedded multimedia card (eMMC)), wireless local area network (WLAN) adapter226and wireless wide area network (WWAN) adapted228. The IC210may include on-chip memory211(e.g., RAM), a central processing unit212, L2 cache213, peripherals214(e.g., Universal Serial Bus (USB), general purpose input/output (GPIO), Inter-Integrated Circuit (I2C), electrophoretic display controller (EPDC), secure digital high capacity (SDHC), ultra SDHC (uSDHC) or the like) and clocks215.

The PMIC202may be configured to manage power requirements of the device102and may be used to place the device in the suspended state200. For example, when the PMIC202is in suspend mode, the device102may stop the CPU212(e.g., place the CPU212into a low power consumption mode), gate the clocks215, place the volatile memory222in a low power consumption mode and disable power to the L2 cache213, nonvolatile memory224, WLAN adapter226and/or WWAN adapter228. However, the PMIC202may maintain power to the on-chip memory211and the peripherals214. Thus, the PMIC202may maintain power to multiple rails without providing a lot of current, reducing power consumption of the device102.

In the low power consumption mode, the volatile memory222is inaccessible to the device102, such that the device102cannot access data stored in the volatile memory222, but the volatile memory222self-refreshes the data using an internal timer so that the data stored in the volatile memory222is maintained. When the clocks215are gated, a majority of the clocks are maintained at a fixed level without high frequency oscillations, resulting in a low power consumption. As the clocks215are gated, the peripherals214are not operating but register settings are preserved because the PMIC202maintains power to the peripherals214. When the WLAN adapter226and the WAN adapter228are disabled, the device102is not connected to an access point, cellular network tower or any other network. While the nonvolatile memory224is disabled, data stored in the nonvolatile memory224is maintained until the device102resumes system interactivity following a restore command (or other event trigger associated with a wake-up event). Upon receiving the restore command, the device102may be unresponsive to a user until the components are enabled and functioning.

FIG. 2Bis a flowchart conceptually illustrating a method for entering the suspended state200. As illustrated inFIG. 2B, the device102may receive (250) a command to enter a suspended state, may gate (252) clocks (e.g., maintain constant values without high speed oscillation), place (254) volatile memory in self-refresh mode, remove (256) power to nonvolatile memory, remove (258) power to a WLAN adapter, remove (260) power to a WWAN adapter, remove (262) power to a L2 cache, place (264) the CPU in low power mode, maintain (266) power to certain rails such as peripherals and on-chip memory and place (268) the PMIC in a suspended state. Upon receiving a restore command, the device102may perform the inverse of the steps illustrated inFIG. 2Bto resume system interactivity and normal operation.

As discussed above, the suspended state may reduce power consumption to a first value (e.g., 650 mA) and may resume system interactivity after a first period of time (e.g., 2 seconds). In contrast, a hibernation state may reduce power consumption to a second value smaller than the first value (e.g., 100 mA) and resume system interactivity after a second period of time longer than the first period of time (e.g., 6 seconds).FIGS. 3A-3Cillustrate a block diagram and a flowchart conceptually illustrating an example method for placing a device in a hibernation state.

As illustrated inFIG. 3A, the PMIC202may be configured to manage power requirements of the device102and may be used to place the device in a hibernation state300. For example, when the PMIC202is in full shutdown mode, the device102may disable power to the on-chip memory211, the CPU212, the L2 cache213, the peripherals214, the clocks215, the volatile memory222, the nonvolatile memory224, the WLAN adapter226and the WWAN adapter228.

When the nonvolatile memory224is disabled, data stored in the nonvolatile memory224is maintained. However, when the volatile memory222is disabled, data stored in the volatile memory222is not maintained. Similarly, data stored in the on-chip memory211, register settings stored in the peripherals214and/or other data is not maintained during the hibernation state300. Therefore, the device102must copy data from the volatile memory222, the on-chip memory211, the peripherals214and/or other components to the nonvolatile memory224prior to entering the hibernation state. Thus, the nonvolatile memory224may store a snapshot or snapshot data that enables the device102to restore data to the volatile memory222, data to the on-chip memory211, register settings to the peripherals214and/or other data or settings prior to resuming system interactivity. Upon receiving a restore command (or other event trigger associated with a wake-up event), the device102may be unresponsive to a user until the components are enabled and the snapshot data is loaded into the on-chip memory211, peripherals214, volatile memory222and/or other components.

FIG. 3Billustrates an example of memory managed by an operating system (OS) kernel310being stored in a snapshot320. As illustrated inFIG. 3B, the memory managed by the OS kernel310may include kernel memory312(e.g., memory associated with the OS), user space processes314(e.g., memory associated with processes running on the device102) and free memory316(e.g., memory currently available). The snapshot320may include a first portion322, which corresponds to a compressed copy of the kernel memory312, and a second portion324, which corresponds to a compressed copy of the user space processes314, thus ignoring the free memory316.

To generate the snapshot320, the device102may store data stored in the user space processes314portion of the memory to the second portion324in the snapshot320. The device102may then generate an atomic copy of data stored in the kernel memory312by freezing contents of volatile memory, freezing a user state and/or freezing state(s) of the input/output system corresponding to each process running on the device102. As used herein, freezing contents refers to capturing the contents at a fixed time, such as when the hibernation command is received or after storing the second portion324to the snapshot320. In some examples, the frozen data may be copied to generate an atomic copy that will not change. For example, data stored in the kernel memory312may be copied to the user space processes314and/or the free memory316portions of the memory managed by the OS kernel310. If the data stored in the kernel memory312is not copied to the user space processes314and/or the free memory316, the data may be changed or modified when generating the snapshot320, such that the first portion322does not correspond to the data stored in the kernel memory312at the fixed time. For example, copying data stored in the kernel memory312without first saving an atomic copy may change values, counter values, which sector saved, etc. associated with a state of the device. To generate the atomic copy, once data stored in the user space processes314is stored as the second portion324of the snapshot320, the device102may copy the data stored in the kernel memory312to the user space processes314and/or free memory316using program code that performs memory to memory copying without changing a state of the memory itself.

After generating the atomic copy, the device102may store the second portion324in the snapshot320and then may store the first portion322in the snapshot320. The device102may generate the atomic copy and store the snapshot320in this particular order so that when the first portion322is restored to the kernel memory312, the data stored in the kernel memory312may correspond to the data stored in the user space processes314at the fixed time.

FIG. 3Cis a flowchart conceptually illustrating a method for entering the hibernation state300. As illustrated inFIG. 3C, the device102may receive (350) a command to enter a hibernation state, may store (352) contents of volatile memory in nonvolatile memory (e.g., generate the first portion and the second portion of the snapshot), store (354) peripheral state(s) in the nonvolatile memory, store (356) a CPU state in the nonvolatile memory, remove (358) power to the components of the device102(excluding the PMI202) and place the PMIC in a hibernation state. Upon receiving a restore command (or other event trigger associated with a wake-up event), the device102may perform the inverse of the steps illustrated inFIG. 3Cto resume system interactivity and normal operation. As discussed above, the hibernation state may offer power savings over a traditional suspended state. However, due to the additional time required to restore the snapshot to the volatile memory and other components, the hibernation state requires more time to fully activate when receiving a restore command.

FIGS. 4A-4Care flowcharts conceptually illustrating methods for entering and exiting a hibernation state. As illustrated inFIG. 4A, the device102may generate (410) a second portion of a snapshot from user space processes and may save (412) the second portion of the snapshot to nonvolatile memory, as described above with regard toFIG. 3B. For example, the device102may generate compressed data corresponding to data associated with the user space processes that is stored in the volatile memory and may save the compressed data to the nonvolatile memory. The device102may generate (414) a first portion of the snapshot from the kernel memory, may save (416) the first portion of the snapshot to a safe location and may copy (418) the first portion of the snapshot from the safe location to the nonvolatile memory. For example, the device102may generate compressed data corresponding to data associated with the kernel memory that is stored in a first location in the volatile memory and may save an atomic copy of the compressed data to a second location in the volatile memory. The device102may then copy the atomic copy from the second location in the volatile memory to the nonvolatile memory as the first portion of the snapshot. The device102may then remove (420) power to components of the device102and enter (422) the hibernation state.

FIG. 4Bis a flowchart conceptually illustrating a first method for loading snapshot data from a hibernation state and resuming system interactivity from the hibernation state. As illustrated inFIG. 4B, the device102may enable (430) power to all components of the device102, may initialize (432) all of the components of the device, may load (434) a first portion of the snapshot to a safe location from the nonvolatile memory, may copy (436) the first portion of the snapshot from the safe location to its original location in volatile memory, may reload (438) the second portion of the snapshot to the volatile memory from the nonvolatile memory and may resume (440) system interactivity (e.g., responsiveness to user input). Using the first method illustrated inFIG. 4B, the device102may completely reload snapshot data to the volatile memory prior to resuming system interactivity. While the first method allows the device102, after resuming system interactivity, to respond to user commands without any perceived latency due to loading the snapshot data, a latency from receiving the restore command to resuming system interactivity is relatively long.

In contrast to the first method, the device102may initialize select components and load the snapshot data directly to the volatile memory from the nonvolatile memory, reducing the latency from receiving the restore command to resuming system interactivity.FIG. 4Cis a flowchart conceptually illustrating a second method for loading snapshot data from a hibernation state and resuming system interactivity from the hibernation state. As illustrated inFIG. 4C, the device102may enable (450) power to components, may initialize (452) the select components, may load (454) snapshot data from nonvolatile memory directly to the volatile memory, may restore (456) peripheral state(s) from the nonvolatile memory, may restore (458) the CPU state from the nonvolatile memory, may jump (460) to a restore point in the OS kernel and may resume (462) the system interactivity. For example, after jumping to the restore point in the OS kernel the device102may enable power to remaining components and initialize the remaining components prior to resuming the system interactivity.

To further reduce the latency from receiving the restore command to resuming system interactivity, the device102may load a portion of the snapshot data prior to resuming system interactivity and may continue loading the snapshot data after resuming system interactivity.FIG. 5is a flowchart conceptually illustrating an example method for loading snapshot data from a hibernation state according to embodiments of the present disclosure.

As illustrated inFIG. 5, the device102may enable (510) power to components, may initialize (512) select components, load (514) preload data of snapshot from nonvolatile memory to volatile memory (e.g., preloading), may activate (516) user space processes and may resume (518) system interactivity. For example, the preload data may include a portion of the snapshot data that is required to resume system interactivity, while remaining portions of the snapshot data may be loaded at a later point in time. Normal device operation (e.g., system interactivity) may be referred to as an “active state.” A period of time between exiting the hibernation state and entering the active state may be referred to as an “unresponsive state.” In the unresponsive state, the device102may display content on the display104and otherwise appear interactive, but the snapshot is being copied to the volatile memory and the device102is unresponsive to user input.

To load the remaining portions of the snapshot data, the device102may determine (520) whether the system is idle. If the device102determines that the system is idle, the device102may load (522) remaining data of the snapshot from the nonvolatile memory to the volatile memory (e.g., idle loading).

If the system is busy and therefore not idle, the device102may perform processes requested by a user and determine (524) if requested data is loaded in the volatile memory. If the requested data is loaded, the device102may loop (526) to step520and continue. However, if the requested data is not loaded from the snapshot, the device102may determine (528) the requested data in the snapshot, may load (530) the requested data from the nonvolatile memory to the volatile memory (e.g., on-demand loading) and may loop (532) to step520. For example, if the user inputs a command associated with a process (e.g., application) that was running prior to the hibernation state, data associated with the process may be stored in the remaining portion of the snapshot that was not loaded to the volatile memory. In order to perform the command, the device102may load the requested data from the snapshot to the volatile memory (e.g., on-demand loading), which may result in a slight latency perceived by the user. For example, after receiving the command, the device102may not perform the command and display the requested data until the device102loads the requested data from the nonvolatile memory to the volatile memory.

When a process requests data from the snapshot that is not preloaded, the device102may perform an additional step of arbitration to identify the requested data in the snapshot and perform on-demand loading to load the requested data from the snapshot.FIG. 6is a flowchart conceptually illustrating an example method for accessing data on demand according to embodiments of the present disclosure. As illustrated inFIG. 6, the device102may receive (610) a command associated with a process and may determine (612) first data associated with performing the command. If the first data wasn't preloaded, the device102may determine (614) that the first data is not available in volatile memory, may determine (616) that the first data is available in nonvolatile memory, may load (618) the first data from the nonvolatile memory to the volatile memory and may display (620) a user interface based on the first data.

If the device102selects a small portion of the snapshot data as preload data (e.g., data loaded during preloading in step514), the device102may resume system interactivity relatively fast and may load the remaining data during idle loading without any latency perceived by the user. However, during preloading, the device102may load a relatively high number of sectors at a time (e.g., 100 to 125 sectors) as read access is much faster than on-demand access due to limitations caused by a controller of the nonvolatile memory. In contrast, the device102may load a relatively small number of sectors at a time (e.g., 4 to 8 sectors) during on-demand loading. Thus, while the device102may resume system interactivity relatively fast, if the user requests data that isn't preloaded, the on-demand loading may load the data at a much slower transfer rate and result in additional latency perceived by the user.

To reduce the latency perceived by the user, the device102may predict processes and corresponding data that are likely to be requested by the user after resuming from the hibernation state and may add the corresponding data to the preload data. For example, the device102may identify processes running when the hibernation command is received and may associate data corresponding to the running processes with preload data to be loaded during preloading. As a result, the data corresponding to the running processes will be loaded prior to resuming system interactivity in step518. Thus, while increasing an amount of preload data may result in a slight increase in time before the device102resumes system interactivity, the user is less likely to request data that isn't loaded in the volatile memory, reducing a latency caused by loading the requested data using on-demand loading.

FIGS. 7A-7Bare charts illustrating example transfer rates associating with loading snapshot data from a hibernation state according to embodiments of the present disclosure.FIG. 7Aillustrates a first transfer rate chart700that corresponds to a minimal amount of preload data. As illustrated inFIG. 7A, preloading710(with a transfer rate of 100-125 sectors per transaction) accesses a large number of sectors sequentially, allowing the device to resume system interactivity after a first period of time (e.g., <6 seconds). However, when the user requests data that isn't preloaded from the snapshot, on-demand loading712(with a transfer rate of 4-8 sectors per transaction) accesses a small number of sectors over a period of time, resulting in a latency perceived by the user. When the device102is idle, idle loading714may load the remaining sectors.

In contrast,FIG. 7Billustrates a second transfer rate chart750that corresponds to additional data being associated with preload data and loaded during preloading. As illustrated inFIG. 7B, preloading760(with a transfer rate of 100-125 sectors per transaction) accesses a large number of sectors sequentially, allowing the device to resume system interactivity after a second period of time (e.g., 6 seconds). As a majority of the snapshot data is preloaded, a majority of data requested by the user after resuming system interactivity is already loaded into the volatile memory. Thus,FIG. 7Billustrates on-demand loading762occurring for a small amount of data requested by the user that isn't preloaded from the snapshot, resulting in a reduced latency perceived by the user. When the device102is idle, idle loading764may load the remaining sectors.

FIG. 8is a flowchart conceptually illustrating an example method for determining preload data according to embodiments of the present disclosure. As illustrated inFIG. 8, the device102may receive (810) a hibernation command, may determine (812) processes that are running, may determine (814) a list of processes to be preloaded after hibernation and may determine (816) a weighting associated with each of the processes in the list. The device102may scan (818) list(s) of virtual memory areas (VMAs) for processes included in the list, may determine (820) that VMAs contain memory pages in a page cache and/or volatile memory, may select (822) the memory pages as preload data to be loaded during preloading, store (824) the preload data and enter (826) the hibernation state. While steps820and822are illustrated as distinct steps, the device102may use a single-pass algorithm to perform steps820and822simultaneously in a single step or “pass,” such as scanning the list(s) of VMAs and selecting pages in the page cache as preload data in a single loop.

For ease of use, hereinafter “memory pages” may be referred to as “pages.” Virtual memory may refer to a process of storing data in volatile memory and/or nonvolatile memory in order to increase an amount of memory available to an application/process beyond the volatile memory (e.g., physical Random Access Memory (RAM) or the like available on the device102). An example of a page cache is a cache that associates pages (e.g., fixed-length contiguous block of virtual memory that stores data) stored in volatile memory and/or nonvolatile memory with individual applications/processes.

The page cache is a kernel level concept and may include an entire set of pages, such that anything accessed frequently by the kernel memory312is included in the page cache. In contrast, VMAs are a process level concept, such that each process has a corresponding list of VMAs mapping to a set of pages stored in the page cache. For example, a first process may be associated with a first list including twenty VMAs, whereas a second process may be associated with a second list including fifteen VMAs. The overall page cache may be relatively large, while the device102may select only a subset of the overall page cache as the preload data (e.g., a third, a quarter or the like). The number of pages from the page cache selected as the preload data varies over time based on a frequency of use. For example, if the kernel memory310frequently accesses a first number of pages in the page cache at a first time and a second number of pages in the page cache at a second time, first preload data associated with the first time may include the first number of pages and second preload data associated with the second time may include the second number of pages.

To generate the preload data, the device102may scan the list of VMAs for each individual process in order to find the list of pages available and may then determine if the available pages are stored in the page cache. The device102may select a first portion of the available pages (that are stored in the page cache) to include in the preload data and may ignore a second portion of the available pages (that are not stored in the page cache). Additionally or alternatively, the device102may use multiple techniques to select the first portion to include in the preload data using selection criteria. For example, the device102may select entire sets of pages associated with each user space process to include in the preload data, resulting in a large amount of preload data. To reduce the amount of preload data, the device102may instead use the selection criteria to select a subset of pages associated with each user space process. For example, the device102may select a specific address range associated with each user space process, may select file pages associated with each user space process, may select all active file pages associated with each user space process, may select all file anonymous pages or the like. However, the device102may select the subset of pages using techniques known to one of skill in the art without departing from the present disclosure.

Further, the device102may determine the list using multiple techniques. In a first example, the device102may determine the list to include all running processes at the time that the hibernation command is received. In a second example, the device102may determine the list to include running processes that have been accessed by the user within a period of time prior to the hibernation command being received (e.g., processes that the user opened within the last five minutes). In a third example, the device102may determine the list to include running processes using criteria that indicate that the user has used the process extensively, such as processes that have received a number of inputs above a threshold (e.g., user interacted with the process extensively), have been running for a period of time above a threshold (e.g., process has continued to run over a long time), have been displayed to the user for a period of time above a threshold (e.g., process has been displayed on the screen a long time) and/or are associated with a quantity of data above a threshold (e.g., process may access a lot of data in volatile memory). However, the disclosure is not limited thereto and the device102may determine the list using other techniques. For example, the device102may determine the list to include non-running processes that are frequently accessed by the user without departing from the disclosure.

Additionally or alternatively, the device may determine the list based on the weighting. Thus, the device102may determine a weighting associated with each of the running processes and may narrow the list based on the weighting. For example, the device102may associate a more recently accessed process with a higher weight than a less recently accessed process. Thus, a first process accessed 20 seconds prior to the hibernation command may be associated with a first weight while a second process accessed 2 minutes prior to the hibernation command may be associated with a second weight lower than the first weight. Additionally or alternatively, the device102may associate a first process that has been running for ten minutes with the first weight while a second process that has been running for two minutes may be associated with the second weight.

Based on the individual weights indicating a priority of the processes, the device102may select processes to include in the list of processes to be preloaded after hibernation. As a first example, the device102may select processes that have a weight above a threshold. Thus, if many processes are running on the device102and have weights above the threshold, the device102may select a large number of processes, whereas if few processes are running on the device102and have weights above the threshold, the device102may select a small number of processes. As a second example, the device102may select a fixed number of processes in order of individual weights. Thus, the device102may select the five processes associated with the five highest weights, regardless of the weight. In a third example, the device102may select a variable number of processes in order of weight so that the preloading is performed in a fixed period of time. For example, a first process may have a first weight and correspond to a first amount of data while a second process may have a second weight lower than the first weight and may correspond to a second amount of data. The device102may determine that, based on the first amount of data and the second amount of data, the preloading would take longer than the fixed amount of time and may select the first process but not the second process. The present disclosure is not limited thereto and the device102may select the processes using other techniques without departing from the disclosure.

FIG. 9is a flowchart conceptually illustrating an example method for determining an amount of preload data according to embodiments of the present disclosure. As illustrated inFIG. 9, the device102may determine (910) a number of running processes, may determine (812) how recent processes were accessed, may optionally determine (914) commonly used processes based on user history or other data, and may determine (916) a weighting for the processes. The device102may select (918) first processes based on weighting, may estimate (920) a first period of time to load data associated with the first processes and may determine (922) if the first period of time is above a threshold. If the first period of time is above the threshold, the device102may loop (924) to step918and select a reduced number of first processes based on the weighting. If the first period of time is below the threshold, the device102may generate (926) a list of the first processes, may identify (928) pages associated with the first processes in the page cache and may store (930) the pages as preload data in the snapshot.

As discussed above with regard toFIGS. 2A-3C, the device102may reduce power consumption by entering a suspended state or a hibernation state. For example, the suspended state may consume a first amount of power (e.g., 650 mA) while the hibernation state may consumer a second amount of power (e.g., 100 mA) that is lower than the first amount of power. Thus, to improve battery life of the device102and reduce overall power consumption, the device102may enter the hibernation state whenever the device is idle. However, each time the device102enters the hibernation state the device102may store data from volatile memory to a snapshot in nonvolatile memory, such as solid state storage like embedded multimedia card (eMMC), that has a finite lifetime expectancy. For example, the nonvolatile memory may write to an individual sector a fixed number of times (e.g., 2,000 times) before receiving read/write errors associated with the sector, although each individual sector is different. To prolong a useful life of the nonvolatile memory, the nonvolatile memory may include a controller that performs wear leveling to evenly distribute read/write commands throughout the sectors. However, after entering the hibernation state a number of times, an amount of sectors receiving read/write errors rises above a threshold and the nonvolatile memory reaches its finite lifetime expectancy.

In order to prolong the useful life of the nonvolatile memory, and therefore reduce power consumption of the device102by enabling the device102to enter the hibernation state over a longer period of time, the device102may limit a frequency that the device102enters the hibernation state. For example, after a first number of “cumulative hibernations” (e.g., the device102enters the hibernation state a first number of times over a total lifetime of the device102), the device102may limit the device to a fixed number of “session hibernations” (e.g., the device102enters the hibernation state a maximum of the fixed number of times over a period of time).

The device102may determine a total number of hibernations (e.g., total number of times that the device102entered the hibernation state over the total lifetime of the device102) and may compare the total number of hibernations to one or more cumulative thresholds. For each of the cumulative thresholds, the device102may determine a corresponding session threshold (e.g., maximum number of times that the device102may enter the hibernation state for each session or interval). For example, the device102may determine a first cumulative threshold (e.g., 50% of lifetime expectancy) associated with a first session threshold (e.g., entering the hibernation state a maximum of 10 times per day) and a second cumulative threshold (e.g., 75% of lifetime expectancy) associated with a second session threshold (e.g., entering the hibernation state a maximum of 5 times per day). Thus, the device102may enter the hibernation state an unlimited amount of times per day until the total number of hibernations is above the first cumulative threshold (e.g., total number of hibernations >50% of lifetime expectancy), at which point the device102may enter the hibernation state up to the first session threshold (e.g., a maximum of 10 hibernations per day). Once the device102reaches the first session threshold (e.g., 10 hibernations in one day), the device102may enter the suspended state instead of the hibernation state until an expiration of the session (e.g., until the next day). After the total number of hibernations is above the second cumulative threshold (e.g., total number of hibernations >75% of lifetime expectancy), the device102may enter the hibernation state up to the second session threshold (e.g., a maximum of 5 hibernations per day). Once the device102reaches the second session threshold (e.g., 5 hibernations in one day), the device102may enter the suspended state instead of the hibernation state until an expiration of the session (e.g., until the next day).

The device102may compare the total number of hibernations to any number of cumulative thresholds. In some examples, the device102may include a cumulative counter that increments each time the device102enters the hibernation state, such that an output of the cumulative counter corresponds to the total number of hibernations. Similarly, the device102may include a session counter that increments each time the device102enters the hibernation state and resets to zero at the end of the session, such that an output of the session counter corresponds to the number of hibernations per session.

The session threshold may correspond to fixed intervals of time (e.g., hourly, daily, weekly, etc.) and/or to variable intervals of time (e.g., each time the device102is on battery power, resetting when the device102is being charged or each time the device102is powered on, resetting when the device102is powered off). Thus, a number of times that the device102enters the hibernation state may vary over time and the device102may determine an interval associated with the session based on usage of the device102. For example, if the device102is charged once a week or less, the device102may associate the session threshold with a weekly interval, thus limiting the device102to hibernating a maximum number of times per week to reduce power consumption and prolong the battery life. In contrast, if the device102is charged twice a week or more, the device102may base the session threshold on the frequency of charging, thus limiting the device102to hibernating a maximum number of times each time that the device102runs on battery power. This may avoid a situation where a battery of the device102lasts a first duration early in the week (when the device102enters the hibernation state) and a second duration later in the week (when the device102has exceeded the session threshold and enters the suspended state instead, consuming more power).

FIGS. 10A-10Dillustrate examples of extending a length of time before failure by using thresholds according to embodiments of the present disclosure. As illustrated inFIG. 10A, the device102may not include cumulative thresholds and/or session thresholds and may perform unlimited hibernations for the lifetime of the device102, as indicated by a first threshold chart1000. As the device102performs unlimited hibernations, a first hibernation chart1002illustrates that the device102hibernates at a first rate until a total number of hibernations is equal to a life expectancy of the nonvolatile memory. Once the total number of hibernations exceeds the life expectancy, the device102must enter the suspended state instead of the hibernation state, increasing a power consumption of the device102and therefore reducing battery life. While the number of hibernations over time may vary, the hibernation chart1002illustrates the first rate as a constant value for ease of explanation.

As illustrated inFIG. 10B, the device102may include a first cumulative threshold (e.g., at 50% of life expectancy) and a corresponding first session threshold (e.g., 10 hibernations per session), as indicated by a second threshold chart1010. A second hibernation chart1012illustrates that the device102hibernates at a first rate until a total number of hibernations is equal to the first cumulative threshold (e.g., 50% of the expected life expectancy) and at a second rate thereafter until the total number of hibernations is equal to the life expectancy of the nonvolatile memory. The second rate may be limited by the first session threshold such that the device102may enter the hibernation state a maximum number of times (e.g., 10) per session. As illustrated in the second hibernation chart1012, the device102continues to hibernate for a longer period of time, compared to the first hibernation chart1002, before the total number of hibernations exceeds the life expectancy of the nonvolatile memory.

As illustrated inFIG. 10C, the device102may include a first cumulative threshold (e.g., at 50% of life expectancy) and a corresponding first session threshold (e.g., 10 hibernations per session) and a second cumulative threshold (e.g., at 75% of life expectancy) and a corresponding second session threshold (e.g., 5 hibernations per session), as indicated by a third threshold chart1020. A third hibernation chart1022illustrates that the device102hibernates at a first rate until a total number of hibernations is equal to the first cumulative threshold (e.g., 50% of the life expectancy), at a second rate until the total number of hibernations is equal to the second cumulative threshold (e.g., 75% of the life expectancy), and at a third rate thereafter until the total number of hibernations is equal to the life expectancy of the nonvolatile memory. The second rate may be limited by the first session threshold such that the device102may enter the hibernation state a first maximum number of times (e.g., 10) per session and the third rate may be limited by the second session threshold such that the device102may enter the hibernation state a second maximum number of times per session that is lower than the first maximum (e.g., 5). As illustrated in the third hibernation chart1022, the device102continues to hibernate for a longer period of time, compared to the second hibernation chart1012, before the total number of hibernations exceeds the life expectancy of the nonvolatile memory.

In some examples, the device102may set a maximum number of hibernations per session to a value of one to maximize the period of time that the device102may hibernate at least once per session. As illustrated inFIG. 10D, the device102may include a first cumulative threshold (e.g., at 50% of life expectancy) and a corresponding first session threshold (e.g., 10 hibernations per session) and a second cumulative threshold (e.g., at 75% of life expectancy) and a corresponding second session threshold (e.g., 1 hibernation per session), as indicated by a fourth threshold chart1030. A fourth hibernation chart1022illustrates that the device102hibernates at a first rate until a total number of hibernations is equal to the first cumulative threshold (e.g., 50% of the life expectancy), at a second rate until the total number of hibernations is equal to the second cumulative threshold (e.g., 75% of the life expectancy), and at a third rate thereafter until the total number of hibernations is equal to the life expectancy of the nonvolatile memory. The second rate may be limited by the first session threshold such that the device102may enter the hibernation state a first maximum number of times (e.g., 10) per session and the third rate may be limited by the second session threshold such that the device102may enter the hibernation state once per session. As illustrated in the fourth hibernation chart1032, the device102continues to hibernate for a longer period of time, compared to the third hibernation chart1022, before the total number of hibernations exceeds the life expectancy of the nonvolatile memory.

FIG. 11is a flowchart conceptually illustrating an example method for determining cumulative thresholds and corresponding session thresholds according to embodiments of the present disclosure. As illustrated inFIG. 11, the device102may receive (1110) an estimated number of hibernations before write/read errors occur in nonvolatile memory, which may be determined during testing of several types of nonvolatile memory devices. The device102may receive (1112) vendor statistics associated with a particular type of nonvolatile memory device from a particular vendor and may estimate (1114) a life expectancy of the nonvolatile memory based on the estimated number of hibernations before errors occur and the vendor statistics. Optionally, the device102may determine (1116) a half-life from the life expectancy and may determine cumulative thresholds based on the half-life. The device102may determine (1118) a first cumulative threshold and determine (1120) a corresponding session threshold that corresponds to the first cumulative threshold.

Optionally, the device102may determine (1122) a first battery threshold corresponding to the first cumulative threshold. The battery threshold may be a high threshold (e.g., 75% battery life) where the device102may not enter the hibernation state as battery conservation is not an issue, or the battery threshold may be a low threshold (e.g., 15-20% battery life) where the device102may not enter the hibernation state as there isn't enough battery life to perform hibernation. As a first example of the high threshold, if the device102determines that a charge of the battery is above the first battery threshold, the device102may determine not to hibernate and may enter a suspension state instead, as battery life is not yet an issue. Thus, the device102may enter a hibernation state when the charge of the battery falls below the first battery threshold and may instead enter a suspended state when the charge of the battery is above the first battery threshold. As a second example of the low threshold, the device102may determine that the charge of the battery is below the first battery threshold and may determine not to hibernate, as the device102may exhaust the remaining battery life while entering the hibernation state. For example, entering the hibernation state may consume a variable amount of battery life (e.g., roughly 10%) and if the battery is exhausted prior to entering the hibernation state, data may be lost or not accurately stored. In addition, the device102may be unresponsive to the user and unable to indicate that there is low battery during the hibernation state. Thus, the device102may enter the hibernation state when the charge of the battery is above the first battery threshold and may enter the suspended state when the charge of the battery is below the first battery threshold.

The device102may determine (1124) whether to generate additional cumulative thresholds. If the device102determines to generate additional cumulative threshold(s), the device102may loop (1126) to step1118and perform steps1118-1122for each of the additional cumulative threshold(s). If the device102determines not to generate additional cumulative threshold(s), the process may end.

FIG. 12is a flowchart conceptually illustrating an example method for determining whether to place a device in a hibernation state according to embodiments of the present disclosure. As illustrated inFIG. 12, the device102may receive (1210) a hibernation command, may determine (1212) a first value of cumulative hibernations and may determine (1214) that the first value is above a first cumulative threshold. The device102may determine (1216) a first session threshold corresponding to the first cumulative threshold, determine (1218) a second value of session hibernations and may determine (1220) whether the second value is above the first session threshold. If the second value is below the first session threshold, the device102may enter (1222) the hibernation state. If the second value is above the first session threshold, the device102may enter (1224) the suspended state.

FIG. 13illustrates a block diagram conceptually illustrating example components of a system100including a device102. Other components not illustrated may also be included in the device102without departing from the disclosure. In operation, the system100may include computer-readable and computer-executable instructions that reside in storage1308on the device102. The device102may be a mobile electronic device including a battery. Examples of mobile electronic devices may include computers (e.g., a laptop, a tablet or the like), portable devices (e.g., a camera (such as a 360° video camera), smart phone, tablet or the like), media devices or the like. The device102may also be a component of any of the abovementioned devices or systems.

As illustrated inFIG. 13, the device102may include an address/data bus1302for conveying data among components of the device102. Each component within the device102may also be directly connected to other components in addition to (or instead of) being connected to other components across the bus1302.

The device102may include one or more controllers/processors1304comprising one-or-more central processing units (CPUs) for processing data and computer-readable instructions and a memory1306for storing data and instructions. The memory1306may include volatile random access memory (RAM), non-volatile read only memory (ROM), non-volatile magnetoresistive (MRAM) and/or other types of memory. The device102may also include a data storage component1308for storing data and processor-executable instructions. The data storage component1308may include one or more non-volatile storage types such as magnetic storage, optical storage, solid-state storage, etc. The device102may also be connected to a removable or external non-volatile memory and/or storage (such as a removable memory card, memory key drive, networked storage, etc.) through the input/output device interfaces1310.

The device102includes input/output device interfaces1310. A variety of components may be connected to the device102through the input/output device interfaces1310. The input/output device interfaces1310may be configured to operate with a network1320, for example a wireless local area network (WLAN) (such as WiFi), Bluetooth, ZigBee and/or wireless networks, such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, etc. The network1320may include a local or private network or may include a wide network such as the internet. Devices may be connected to the network1320through either wired or wireless connections.

The input/output device interfaces1310may also include an interface for an external peripheral device connection such as universal serial bus (USB), FireWire, Thunderbolt, Ethernet port or other connection protocol that may connect to networks1320. The input/output device interfaces1310may also include a connection to an antenna (not shown) to connect one or more networks1320via a wireless local area network (WLAN) (such as WiFi) radio, Bluetooth, and/or wireless network radio, such as a radio capable of communication with a wireless communication network such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, etc.

The device102further includes a hibernation module1324, which may comprise processor-executable instructions stored in storage1308to be executed by controller(s)/processor(s)1304(e.g., software, firmware), hardware, or some combination thereof. For example, components of the hibernation module1324may be part of a software application running in the foreground and/or background on the device102. The hibernation module1324may control the device102as discussed above, for example with regard toFIGS. 1A, 1B, 5, 6, 8, 9, 11 and/or 12. Some or all of the controllers/modules of the hibernation module1324may be executable instructions that may be embedded in hardware or firmware in addition to, or instead of, software. In one embodiment, the device102may operate using an Android operating system (such as Android 4.3 Jelly Bean, Android 4.4 KitKat or the like), an Amazon operating system (such as FireOS or the like), or any other suitable operating system.

Executable computer instructions for operating the device102and its various components may be executed by the controller(s)/processor(s)1304, using the memory1306as temporary “working” storage at runtime. The executable instructions may be stored in a non-transitory manner in non-volatile memory1306, storage1308, or an external device. Alternatively, some or all of the executable instructions may be embedded in hardware or firmware in addition to or instead of software.

The components of the device102, as illustrated inFIG. 13, are exemplary, and may be located a stand-alone device or may be included, in whole or in part, as a component of a larger device or system.

The concepts disclosed herein may be applied within a number of different devices and computer systems, including, for example, general-purpose computing systems, server-client computing systems, mainframe computing systems, telephone computing systems, laptop computers, cellular phones, personal digital assistants (PDAs), tablet computers, video capturing devices, video game consoles, speech processing systems, distributed computing environments, etc. Thus the modules, components and/or processes described above may be combined or rearranged without departing from the scope of the present disclosure. The functionality of any module described above may be allocated among multiple modules, or combined with a different module. As discussed above, any or all of the modules may be embodied in one or more general-purpose microprocessors, or in one or more special-purpose digital signal processors or other dedicated microprocessing hardware. One or more modules may also be embodied in software implemented by a processing unit. Further, one or more of the modules may be omitted from the processes entirely.

Embodiments of the present disclosure may be performed in different forms of software, firmware and/or hardware. Further, the teachings of the disclosure may be performed by an application specific integrated circuit (ASIC), field programmable gate array (FPGA), or other component, for example.