First we need to determine the current scenario of a process based on inputs from various browser components. For example, the Chrome render process has a status about background state, which indicates whether the process is foreground or background scenario. For another example, Chrome has an Ad Tagging mechanism to detect ads and the resources they load in the browser. Ad Tagging works by matching resource requests against a filter list to determine if they’re ad requests. An iframe will be marked as an ad iframe if its url matches the filter list, if the tagged script is involved in the creation of the iframe, or if its parent frame is an ad iframe. If all frames are ad frames, the render process would be tagged as an ad process. The browser collects all these inputs and uses a prioritization mechanism to decide the overall mode for the process. Based on the scenario, we adopt an appropriate scheduling policy next.
The scheduling policy varies based on the device status. As shown in Figure 1, the browser will monitor the power status of the device via APIs provided by the OS, including the battery level, charging status and the thermal state. For hybrid core scheduling, two stages are defined below.
The first one is the normal stage, which means the battery level is over 20% or the device is charging, meanwhile the thermal state is normal. In this stage, the users care more about the performance than power consumption, so we only schedule low priority threads/processes to efficient cores, like the background processes or the threads handling low priority tasks such as logging/profiling.
The second one is the critical stage, which means the battery level is very low without charging, or the device is in critical thermal states, or the web developer explicitly wants to enter power saving mode, like using battery-savings meta tag. In this stage, we’re going to apply more aggressive policies to save more power, prolong device usage time or avoid thermal throttling due to high CPU temperature. Under this circumstance, many threads/processes in normal priority will be scheduled to efficient cores as long as they are not involved in UX critical tasks.
There is some work required to be done to make Chrome utilize OS capability. Battery and thermal status are two important factors to UX. Based on them, Chrome could make appropriate policies to balance performance and power consumption. Previously, there was only battery status exposed to Chrome. Our team has landed a thermal status notification feature in Chrome. In the feature, we introduced 4 thermal levels: Nominal, Fair, Serious, and Critical referring to Apple’s Thermal Hinting API. So that Chrome can get the real-time thermal status. With battery level, charging and thermal status reported, Chrome would decide which stage to enter and apply different scheduling policies.
Furthermore, we have built a bridge between Chrome threads and efficient cores on Chrome OS using the existing cgroup mechanism. Background priority threads are placed in a specific cgroup, which has a specified CPU set. On hybrid core platforms, efficient cores are likely to be allocated for the group. So if we want to schedule unimportant threads to efficient cores to execute, we can lower the thread priority and put them in the non-urgent cgroup. The scheduling is dynamic. When the threads become important (e.g. switch to foreground), we would raise the thread priority to normal right away, hence remove from the specific cgroup.
We use the local build Chromium browser to evaluate the power impact of hybrid core scheduling per each scenario, currently focusing on background renderer processes, ads processes, and idle processes (idle is a state defined in the Chrome RAIL model). According to the experiments performed on Alder Lake Chromebook, we observe 4.2% CPU package power reduction for web browsing when scheduling idle processes to efficient cores, and 3.8% CPU package power reduction when dispatching advertisement processes. At the same time, we use a 4-tab browsing workload to test the power impact of placing background processes on efficient cores, and see 0.9% CPU package power reduction. The power saving would be larger when the number of background tabs and page activities increase.
The experiment data shows that we achieve distinct power reduction by utilizing hybrid core capability in Chromium browser to schedule non-UX critical processes/threads to efficient cores in chosen scenarios, which helps extend device battery life.