Energy-aware process scheduling in linux

Figure 1: Two processes that get scheduled the same CPU time by CFS but significantly differ in their energy consumption.

We demonstrate this discrepancy between CPU and energy consumption with a simple experiment. Figure 1 shows the energy consumption of two processes that are run on Linux with CFS, which allocates each of the processes roughly the same CPU time. The two processes that execute two Python programs. Process 1 is memory-intensive: it repeatedly reads and writes large byte-arrays into heap memory, while process 2 is CPU-intensive: it repeatedly computes SHA256 on long strings (see §5 for the full evaluation setup). We measure each process’s energy consumption using Wattmeter. The experiment shows that despite the fact that both processes are scheduled almost identical CPU time, process 2 consumes about 50% more energy than process 1. In general, variability in energy consumption can stem from factors such as the usage of different CPU instructions, memory consumption, and the cache hit rate [17]. Linux today has no awareness of this variability in energy consumption across processes.

At the moment, Intel only supports CPU-socket-level measurement, and not per-core measurements. With this hardware limit, Wattmeter is unable to obtain accurate perprocess energy consumption for parallel processes running on CPUs within the same socket. Fortunately, AMD’s Zen architecture does offer per-physical-core energy counters, and there has been ongoing discussions and development for Linux support for exposing these data through perf_event [20].

EFS has a simple goal of balancing energy across processes, while maintaining high CPU utilization. The latter is important, because it ensures tasks make forward progress (e.g., a trivial solution to equalizing energy would be to simply shut the entire server down). To do so, EFS builds on top of CFS to take power into account. The CFS algorithm keeps track of the virtual runtime (vruntime) of each process, which is the real runtime weighted by each process’s nice value. At each scheduling decision, CFS picks the process with the lowest vruntime. EFS works similarly: it first computes vruntime, and the difference is that it further scales vruntime with the an additional coefficient vpower to compute venergy, which is used to make scheduling decisions in place of vruntime.

Figure 3: EFS equalizes the energy consumption of two processes with different power consumption profiles.

However, cgroup does not offer energy-related allocations or management.

Figure 3 shows the effect of EFS on the CPU and energy shares between the two processes. With an interval of 0.1 seconds, we measured how much time and energy has been used by each process. Then, the time and energy share of the process was computed using a sliding window of 0.5 seconds.

The result shows that processes scheduled with EFS only take 1.25% more time to finish: on average, EFS tasks take 10.83 seconds, and CFS tasks take 10.70 seconds. This small overhead also includes the overhead from the ghOSt framework, which means that the overhead from our energy measurements and scheduling policy is even smaller.

There are existing tools for measuring energy and resource consumption for various settings and applications. On Linux and cloud platforms, there are tools for estimating and controlling process- or container-level energy consumption based on RAPL, hardware monitoring, and other instrumentation mechanisms [1, 6, 12, 14, 27, 30]. However, as discussed in §2.1, only Wattmeter offers millisecondscale per-process measurement that is crucial for implementing an energy-aware scheduling policy.