The current implementation of powerd(8), which was introduced in FreeBSD 5.5, is very limited and only monitors the CPU's state. The powerd utility should also power down idle disk and other components to maximize power savings. The plan is to test a range of predictive algorithms and implement the best performer(s) into powerd. The "best performer" is defined as the algorithm that saves the most power while losing the least performance. http://www-flash.stanford.edu/~kinshuk/MCN95.ps presents a good sampling of algorithms that should be tried in powerd.
Additional power savings can be saved by monitoring the hard drive for inactivity and turning the drive off when no activity is detected for an extended period of time. Other devices will also be considered for power savings as the project moves foward.
[Update July 2, 2005] - I am designing the test suite that will be used to profile the various power scaling algorithms. In order to see the real performance characteristics of my work I need to be able to do statistical analysis for each step to see what is working and what is not. Bruno Ducrot and Nate Lawson (my mentors for this project) have suggested some workloads that I need to test for each algorithm.
- Simulated Workloads
- Full CPU stress test - Exercise the CPU with no idle time
- Burst CPU test - Alternate between periods of activity and inactivity. I can adjust the ACTIVITY_PERIOD and INACTIVITY_PERIOD parameters to see how the algorithms deal with different usage scenarios. This test focuses on the effect that "soft" idle times have on the powerd module.
- Disk IO test - Exercise the Disk IO. This test will read and write substantial amounts of data to/from the disk. In order to test the effects disk io have on the powerd module care must be taken to avoid operating out of the cache. By increasing the size of the data sets used and descreasing the avaible cache memory, I can be confident that I am getting the necessary disk io. The access patterns also need to be random so that the disk's caching logic doesn't have a significant effect on the results. This focuses on the effect that "hard" idle times have on the powerd module.
- Desktop application (Real workload(s))
- A good combination of scenarios to test the powerd module under real workloads. This should include using Firefox, random utitilties, mp3 players etc with a pre-determined script. This test should aim to cover any holes that exist between the three simulated workloads.
- NOTE: "Hard" idles and "Soft" idles are terms used in the paper: "Scheduling for Reduced CPU Energy" to distinguish between how a process idles. "Hard" idles are determined by a wait on another device such as a hard drive. "Soft" idles have the possiblilty of being eliminated. At the moment the powerd module can not re-schedule processes so there is not much distiction between "Hard" and "Soft" idles. At a later data however, it may be possible to add support for rescheduling into the kernel to reduce "soft" idles and the seesaw-like effect they can add to a system controlled by powerd.