|
ECOSystem Description
ECOSystem, which stands for Energy-Centric Operating System, is a modified Linux operating system
which manages energy as a first class resource. As it was developed, the original goal of ECOSystem
was to meet a user-specified battery lifetime for the laptop computer it was installed on. For example,
let's hypothesize that a user has a 2 hour plane ride and wants to use the laptop to finish a presentation.
The user also wants to listen to mp3 music in the background. Therefore, the user tells ECOSystem
that he/she wants the battery to last 2 hours and that the presentation application is more important
than the music player.
Once ECOSystem knows how long the battery must last, it can compute how much energy can be drained
from the battery per epoch. Each epoch (a very short time period) this current is doled out proportionally
to the active processes. The unit of this allocation is currentcy, the right to use a certain amount of
current (there is a limit on how long this currentcy can be held). As the process executes, it is charged
for the amount of energy it is using. If the process runs out of currentcy, it must stop executing until
it receives more currentcy in the next epoch.
Right now, the only devices managed by ECOSystem are the CPU, the hard disk, and the wireless card.
All other energy required by the operating system is considered "base cost". As ECOSystem develops, other
devices, like the display, will also be managed by the operating system.
My work on ECOSystem this summer deals with more efficient power management of the hard disk drive.
Now that ECOSystem is able to meet reasonable specified battery lifetimes, we want to incorporate strategies
for energy efficiency. We are working to extend the ECOSystem API specification to allow cooperative
communication between ECOSystem (which right now runs standard applications) and modified, energy-aware
applications. This wil allow applications to pass information to the operating system about which file
operations are most important, and how much currentcy the process is willing to "spend" to perform the disk
access. Hopefully, using this application-specific information, we can more efficiently batch read and
write requests to the disk, allowing the disk to spend more time in idle mode and saving on the high cost
of spinning up and spinning down by having fewer active disk sessions.
Go to top
|
