Our implementation results were disappointing to us - we had hoped to be able to identify a prediction heuristic that resulted in significant energy savings, and we thought that the claims made by previous studies would be born out by experimentation. Although we have found a policy that saves some energy, that policy leaves much to be desired. The policy causes many voltage and clock changes, which may incurr unnecessary overhead; this will be less of a problem as processors are better designed to accommodate those changes. However, the policy did result in both the most responsive system behavior and most significant energy reduction of all the policies we examined.
As with all empirical studies, there are anomalies in our system that we can not explain and that may have influenced our results. We found that the processor utilization does not always vary linearly with clock frequency. Figure 9 shows the processor utilization vs. clock frequency for the MPEG benchmark. There is a distinct ``plateau'' between 162MHz and 176.9MHz. We believe that this delay may be induced by the varying number of clock cycles needed for memory accesses as the processor frequency changes, as shown in Table 3. That table shows the memory access time for EDODRAM for reading individual words or a full cache line; there is an obvious non-linear increase between 162MHz and 176.9MHz. The potential speed mismatch between processor and memory has been noted by others [12], but we have not devised a way to verify that this is the only factor causing the non-linear behavior we noted.
This paper is the first step on an effort to provide robust support for voltage and clock scheduling within the Linux operating system. Although our initial results are disappointing, we feel that they serve to stop us from attempting to devise clever heuristics that could be used for clock scheduling. It may well be that Pering [11] reached a similar conclusion since their later publications discontinued the use of hueristics, but their publications don't describe the implementation of their operating system design or the rational behind the policies used. Furthermore, they don't describe how deadlines are to be ``synthesized'' for applications such as Web, TalkingEditor and Web where there is no clear ``deadline''.
Our immediate future work is to provide ``deadline'' mechanisms in Linux. These deadlines are not precisely the same mechanism needed in a true real-time O/S - in a RTOS, the application does not care if the deadline is reached early, while energy scheduling would prefer for the deadline to be met as late as possible. A further challenge we face will be to find a way to automatically synthesize those deadlines for complex applications.
