Given a particular amount of currentcy per epoch, we investigate proportionally sharing this fixed allotment among competing tasks when some of the currentcy must be spent outside of the CPU. We analyze the effects of CPU scheduling using the default round-robin scheduler minimally modified to check for currentcy, the static energy-based stride scheduler, and our energy-centric scheduler with dynamic shares. We want to show that the energy-centric scheduler can achieve energy use that is proportional to the specified currentcy share of each task, allowing a lower consumption when it is enough to satisfy a task's performance needs. Thus, the first step is to determine whether there is a level of power consumption such that using more power does not produce significantly improved performance.
For the experiment presented, we simultaneously run gqview and ijpeg with equal shares of a varying total allocation. First, we execute each application alone across the range of total allocation levels to see how the performance metric associated with that benchmark behaves. For gqview, configured with a think time of 10 seconds, the delay to completely display the given image decreases with increasing allocations of currentcy (mapped into average power for presentation) until around 6500mW where it levels out at approximately 6.3s. We pit gqview against ijpeg, our CPU-bound benchmark that is always ready to run and whose performance metric, the delay to compress an image file, continues to decline until the maximum power consumption of the processor is reached (e.g., 15.55W). By setting the shares to be equal for the two competing applications, we are giving some benefit to the round robin and stride schedulers. In addition, the power needed by gqview for the disk (i.e., approximately 700mW) represents a relatively small level of consumption diverted to another device, making it more challenging for our energy-centric scheduler to distinguish itself.
Figure 3 shows our results. Figures 3a and 3c give the power consumed by gqview and ijpeg as the allocation increases for each of the three scheduling policies. There are two additional lines on the plot for gqview showing the proportional allocation and the maximum power based on performance. Note that the bars representing the energy-centric scheduler show that gqview receives its appropriate energy share up until the point where it approaches its maximum power requirement. The Linux default scheduler and the energy-based stride scheduler both favor ijpeg at the expense of gqview. In the case of the default Linux scheduler, this is because ijpeg is always competing with gqview for the CPU and its round-robin algorithm gives each 50% and, for gqview, that is only when it is active (not during its think time or disk access). The static energy-based stride scheduler experiences similar problems when gqview and ijpeg are competing for the CPU (with equal share values). Gqview is unnecessarily penalized for voluntarily reducing its energy consumption during idle periods.
Our energy-centric scheduler extends the stride scheduler in two important ways. First, it selects the next task having the lowest amount of currentcy spent relative to its share, and second it dynamically computes a task's stride by including information about past consumption. This allows it to compensate for currentcy consumption of the other device as well as for periods of complete inactivity as in gqview's think time.
From Figures 3b and 3d, we see that with the energy-centric scheduler, gqview's delay approaches its performance of 6.3s when running without competition once it is given enough power. Neither the Linux scheduler or the stride scheduler deliver gqview that level of performance. Meanwhile, the performance level of ijpeg is appropriate to its allocation level. It benefits from redistributed currentcy once gqview's consumption levels out, exceeding its expected performance (of running alone at that allocation level) for each scheduling choice.
