A screenshot of the Battery Manager app (the green flag in the upper left corner shows that the device is in the green state). Accuracy of the proposed method when only one application requests a lifetime warranty (applications marked with asterisks have lifetime requirements). Accuracy of the proposed method when only two applications request a lifetime warranty (applications in parentheses have lifetime requirements).
In addition to this shortened battery life, the unpredictability of battery life due to the high degree of multitasking becomes another source of user dissatisfaction. Most smartphone systems provide tools to monitor remaining battery charge and estimate remaining battery life.
Motivation
The absolute values of the system's energy consumption come from a sensor built into the battery. To ensure system uptime, existing studies typically control power consumption by limiting scheduled applications. For example, if the remaining battery charge is insufficient, you can still ensure battery life by not running low-priority apps or by keeping power consumption low by limiting the running time of apps.
Related Works
Based on an analysis of the energy pattern per wire, a throttling wire, which forces the stop cycle to reduce the energy. consumption, is executed if the consumed energy exceeds the predefined average energy. Compared to existing operating systems that aim to maximize performance and fairness, Vahdat et al. 2000) have designed a system that takes into account the energy efficiency of its energy management policies and proposed a prototype of the ECOSystem (Energy-centric Operating System ) that considers energy as the primary resource of the operating system. To ensure the user's desired battery life, the ECOSystem calculates the available Currentcy of the entire system for each interval and distributes it to each application according to the user's preferences.
Furthermore, some guarantee the battery life of the entire system instead of guaranteeing the life of each application (Flinn and Satyanarayanan, 1999, Bellosa, 2000, Zeng et al., 2002, Zeng et al., 2003). Flautner, Krisztian and Mudge, Trevor, Vertigo: automatic performance tuning for Linux, In 2002, Proceedings of the fifth symposium on Operating systems design and implementation, 105–116. Yuan, Wanghong and Nahrstedt, Klara, Energy-efficient soft real-time CPU scheduling for mobile multimedia systems, In 2003, Proceedings of the Nineteenth ACM Symposium on Principles of Operating Systems, 149–163.
Cheng, Hui and Goddard, Steve, Online energy-aware I/O device scheduling for hard real-time systems, in 2006 Proceedings of the Conference on Design, Automation and Testing in Europe. Nakku Kim, Jungwook Cho and Euiseong Seo, Energy-based accounting and scheduling of virtual machines in a cloud system, in 2011, Proceedings of the 2011 International. Gupta, Evaluating the Effectiveness of Model-Based Power Characterization, In 2011, Proceedings of the USENIX Annual Technical Conference 2011.
Kansal, Aman and Zhao, Feng and Liu, Jie and Kothari, Nupur and Bhattacharya, Arka A., Virtual Machine Power Measurement and Provisioning, In 2010, Proceedings of the First ACM Symposium on Cloud Computing, 39–50.
System Architecture
Of the components in the system, Battery Manager, Activity Manager, Battery Driver and Linux Kernel Scheduler are already included by default in the Android platform, but we suggest to extend them. This service regularly monitors the remaining battery charge and battery temperature obtained by the core, and analyzes the proportion of total system power consumption represented by each device and the amount of power consumed by each application based on the usage of the acquired devices and the scheduled usage time via battery driver and activity manager. Activity Manager records how long each app is running over a period of time, which can help analyze power consumption per app.
The battery driver is a core device driver that reads the remaining battery charge from the circuitry built into the battery and provides this information to the application framework. The lifetime requirement for each application is then provided to the Battery Lifetime Manager in the application framework. Battery Lifetime Manager uses the information from Battery Manager, Activity Manager and Battery Driver to assess the current status of the system.
To this end, Battery Life Manager periodically monitors the amount of power consumed by the battery manager and analyzes how much power each application consumes based on that. If the battery drains fast enough that the application lifetime requirements are not guaranteed, the Kernel Scheduler receives a signal to limit power usage by certain applications. The Battery Life Manager provides the Kernel Scheduler with the current system status and battery usage of each application.
If a power limit is required to ensure the lifetime of each application, the power allocator will determine how much time each application is scheduled for a given period.
System Modes
If the mobile phone recharges the battery in all modes, the power management mode switches to Normal. The power management mode will then change to green mode if the application requires its lifetime in normal mode. Thus, users should abandon the lifetime warranty of an application when the power management state turns black.
If the increasing energy consumption of applications that have no lifetime requirements endangers other applications, the power management status will switch to the red status and the energy consumption of the applications that have suddenly consumed a lot of energy will be limited. If the power management status is not Normal, we assume that the system services have the same lifetime requirements as the application that required the longest lifetime guarantee. Therefore, we consider the energy consumed by threads with the same UID to calculate the application's energy consumption.
In our prototype, we used the variable 1 minute to analyze scheduling information and energy consumption of each application. If the state of energy management is determined by a temporary increase in energy consumption, this will lead to a too rapid transition to the red state and thus to applications that have no lifespan. Even if the user demands a lifetime warranty on the application, the energy management does not change for 4 minutes.
We use the energy consumption model introduced in Section 2-1 to measure the amount of energy that applications consume.
Energy-Constrained Scheduler
When the power management state goes from red, the applications in the freeze queue are released and the normal schedule begins. When the power management state switches to red, the power allocator calculates the average power consumption of applications that have lifetime requirements in the fiscal interval by dividing the reserved power for the applications by the remaining lifetime of each application. After a fiscal interval, the energy available for consumption by queued applications in the new fiscal interval is allocated by the energy allocator to those applications that have lifetime requirements.
The requests that receive the energy will continue to reschedule until their declared energy quota is exhausted. Monitoring application energy consumption in real time during a fiscal interval incurs significant overhead. We found from our experiments that this scheduling method causes multimedia applications such as movies and games to severely degrade QoS in the power-constrained scheduling mode, even though they receive the same amount of processor time as in Green or Yellow.
As shown in Figure 3.7(a), QoS degradation occurs in the energy-constrained scheduling mode because some applications that have no lifetime requirements are frozen while others are scheduled in rapid succession. To avoid this QoS degradation, in the energy-constrained scheduling mode, the scheduling pattern shown in Figure 3.7(b) must be forced to provide the same experiences, such as running other applications together or using a low-performance system. processor. The proposed method attempts to preserve the scheduling patterns of running multimedia applications after entering the energy-constrained scheduling mode by executing the kernel thread as much processor time as the frozen applications are allocated, which leads to competition between the kernel thread and lifetime applications. processor resource requirements.
By using this method, we expect the application to avoid QoS degradation due to the change of scheduling patterns in energy-constrained scheduling mode.
Evaluation
Evaluation Environment
Lifetime Guarantee Accuracy
The "unused" criterion means that the remaining charge of the battery after the required lifetime is guaranteed. In other words, the power management is so conservative that applications that have no lifetime requirements can no longer run in the red state, even though there was enough power. There was some unused energy left at the end of our experiments, but this amount was different after each experiment.
Such prediction errors occur because the number of context switches and the number of timeouts in the Red state are lower than those in other states. Therefore, the number of timer interrupts is greatly reduced to applications that do not have a lifetime. As a result, the unused energy remained after the battery life guarantee by reducing the amount of energy consumed.
As shown in Figure 4-2, the percentage of unused energy increases more by not using mandatory idle propagation. By entering the red state earlier than the ideal case, running apps does not require a lifetime to run, but in each experiment, we can confirm that the battery life of each app is guaranteed. Therefore, to use the energy more aggressively, we need to introduce a method that postpones entering the red state by taking into account the excess energy caused by frozen applications.
However, the chance of failing to guarantee lifetime requirements is likely to be higher due to inaccurate forecasts.
Quality of Multimedia Applications
The video player showed fast movements above 30 FPS in the first second using its given energy, while it showed a FPS value below 5 in the second second because its given energy had been used up in the first second. This situation becomes more serious because the video player buffers the data in the background. The given energy budget is used for on-screen rendering and the remaining energy budget is used for buffering.
Therefore, the energy budget is quickly exhausted and eventually the frames stored in the buffer cannot be retrieved in time. However, we observed that the number of jitters was significantly reduced when forced propagation was used at work.
Conclusion
