figure 1. A hierarchy of resource managers.

resource
Consumer
resource
Manager
resource

Data Center

virtual
Machine
virtual Machine Scheduler
virtual
Machine

Virtual/Physical Machine Mgr.

Physical
Machine
Physical
Machine
Physical
Machine

Physical Machine
OS
CPU Scheduler Physical Memory Management

OS
instance

hypervisor

Physical
CPU
Physical
CPU
Physical
CPU

Operating System Instance

Application Application
Scheduler virtual Memory Subsystem Storage volume Manager
virtual
CPU
virtual
CPU
virtual
CPU

trade off performance for power effi-
ciency (CPU frequency scaling is one
example), while others might offer (for
idle resources) a trade-off of reduced
power consumption versus increased
recovery latency (for example, as with
the ACPI C-states). As such, the act of
a resource manager selecting one re-
source over another (based on power
states) is an important vehicle for mak-
ing such tradeoffs that ideally should
complement the power-management
strategy for individual resources.

 

temporal considerations Some resource managers may also allocate resources in time, as well as (or rather than) space. For example, a timer subsystem might allow clients to schedule some processing at some point (or with some interval) in the future, or a task queue subsystem might provide a means for asynchronous or deferred execution. The interfaces to such subsystems have traditionally been very narrow and prescriptive, leaving little room for temporal optimization. One solution is to provide

figure 2. Benefits of batch processing periodic timers.

time
no timer Batching
(Short Sleep durations, Frequent Wake-ups)

time
After timer Batching
(longer Sleep durations, Fewer Wake-ups)

interfaces to clients that are more descriptive in nature. For example, rather than providing a narrow interface for precise specification of what should happen and when:

 

int schedule _ timer((void)* what(), time _ t when);

 

a timer interface might instead specify what needs to be done along with a description of the constraints for when it needs to happen:

 

int schedule _ timer((void)* what(), time _ t about _ when,

time _ t deferrable _ by, time _ t advancable _ by);

 

Analogous to consolidating load onto fewer sockets to improve spatial resource quiescence, providing some temporal latitude allows the timer subsystem to consolidate and batch process expirations. So rather than waking up a CPU n times over a given time interval to process n timers (incurring some overhead with each wakeup), the timer subsystem could wake the CPU once and batch process all the timers allowable per the (more relaxed) constraints, thus reducing CPU overhead time and increasing power-managed state residency (see Figure 2).

efficient Resource consumption

Clearly, resource managers can contribute much to the overall efficiency of the system, but ultimately they are forced to work within the constraints and requests put forth by the system’s resource consumers. Where the constraints are excessive and resources are overallocated or not efficiently used, the benefits of even the most sophisticated power-management features can be for naught while the efficiency of the entire system stack is compromised.

Well-designed, efficient software is a thing of beauty showing good proportionality between utilization (and useful work done) and the amount of resources consumed. For utopian software, such proportionality would be perfect, demonstrating that when no work is done, zero resources are used; and as resource utilization scales high-