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-