Hardware Reference
In-Depth Information
framework is able to automatically identify the current task state and accordingly
map this on a congruence class defining a limited set of eligible operating points.
Identifying a congruence class is not sufficient to actually select the best OP. To that
purpose two more concepts are considered in the framework: the constraints and the
optimization strategy. A constraint is a requirement on a specific OP value that could
be asserted by either applications or device drivers. The core framework collects
constraints asserted by all system entities and use them to invalidate the OPs that
are not compatible with them. This first mechanism could thus reduce the number of
eligible OPs available in the current congruence class. Finally, where more OPs that
are still valid after considering all the constraints, the optimization strategy defines
the ultimate rules to give each valid OP a relative preference value.
The framework is mostly an architectural proposal which requires customization
efforts for each specific platform in order to be effectively used. The core frame-
work provides just the glue code with the basic mechanisms to define the abstraction
objects, but their actual definition is entirely an effort of the platform engineer. Sec-
ondly, the definition of the abstraction objects is a rather complex problem by itself
since it requires a deep knowledge of a platform as a whole. Nevertheless, this re-
mains one of the more interesting proposal for a centralized cross-layer optimization
framework which is worth to consider especially in the case of relatively simple and
dedicated embedded systems that require fine grained and low-overhead control.
6.4.2.2
QoS-PM Framework
The QoS-PM Framework has been the first attempt to implement a sufficiently generic
framework to support distributed cross-layer power management within the Linux
kernel. This kernel infrastructure has been proposed by Intel, essentially as an exten-
sion to the pre-existing Latency Framework , for optimizing the power consumption
of a WiFi network interface [ 6 ].
The basic idea of this framework is to define a set of QoS parameters which are
available to both applications and in-kernel code to assert requirements on them.
The parameters defined are sufficiently abstract not to reduce the portability of the
solution; in the current implementation they represent network throughput, network
time-out and system latency. Of course this initial set of parameters is quite lim-
ited, but could be easily extended provided that the new parameters are completely
platform independent. Well-defined and simple methods can be used to assert require-
ments on each of these parameters which are then aggregated by the core framework.
The requirements aggregation is performed using a simple boundary function, i.e.,
the maximum or the minimum of the requests is considered to be the more restrictive
value for the parameters. Drivers and other kernel code could declare their interest on
a particular parameter by simply subscribing the corresponding notification chain.
Once a new request on a parameter happens, the aggregated value is notified by the
core framework to each driver or subsystem which has registered to the notification
chain associated to that parameter.
Search WWH ::




Custom Search