Hardware Reference
In-Depth Information
Once a driver is notified by a new aggregated value for a certain parameter of inter-
est, it could exploit that information in order to fine tune its local optimization policy.
For instance, in the current implementation of the CPUidle framework described so
far, when an idle state transition has to be decided, it takes into consideration the
system latency requirements. This information is valuable since we know that the
exit time from an idle state could be highly varying and thus could have also a great
impact on the experienced latency of the system. The behavior implemented in this
framework is thus that of a distributed control model. The framework core collects
requests from applications and provides a simple optimization policy, based on the
boundary aggregation, that deliver some tuning parameters to many other special-
ized policies. It is worth noticing that the current implementation of the notification
mechanism support only a best-effort approach. Once a driver receives a notifica-
tion of an update on a certain parameter, it could decide to do its best to satisfy the
requirements. But if that is not possible, there is no feedback delivered up to the
requesting user-space application.
The best-effort nature of the current implementation, along with the simple aggre-
gation functions supported, are justified by the need to keep the QoS framework as
simple as possible. By this design choice, the paradigm of a cross-layer distributed
approach to power management is easily exported to the Linux kernel. Nevertheless
these are also some of the main limitations of the current implementation and mo-
tivate the research interest in this specific area of power management at operating
system level.
6.4.2.3
Constrained Power Management
The CPM framework [ 1 ] is the first complete and comprehensive implementation
of the hierarchical power manager concept for the Linux kernel. This framework
is based on the design of a single coordination entity which allows both to exploit
a system-wide view of resources availability and to aggregate all the application
requirements.
Resource availability is defined by device drivers, in a platform independent
way, and this information is exploited by the framework to support the system-wide
optimization policy with fine-details and improved portability. The fine-details are
granted by the low-level information collected at run-time by drivers, thus improving
the portability of the control solution. By changing an architecture or even a single
device, the new information is automatically detected.
Application requirements are collected by a single and well defined user-space
interface. The framework aggregates all the requirements and translates them in a
set of constraints for the global policy.
At run-time, a global optimization policy could exploit all the information col-
lected either by drivers and applications: the former defining resource availability
while the latter asserting QoS requirements. This information could be used effec-
tively to solve a multi-objective optimization problem targeted to identify the best
system-wide configuration. For scalability reasons, this configuration could not be
Search WWH ::




Custom Search