65 lines
2.7 KiB
Plaintext
65 lines
2.7 KiB
Plaintext
|
PM Quality Of Service Interface.
|
||
|
|
|
||
|
|
This interface provides a kernel and user mode interface for registering
|
||
|
|
performance expectations by drivers, subsystems and user space applications on
|
||
|
|
one of the parameters.
|
||
|
|
|
||
|
|
Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
|
||
|
|
initial set of pm_qos parameters.
|
||
|
|
|
||
|
|
Each parameters have defined units:
|
||
|
|
* latency: usec
|
||
|
|
* timeout: usec
|
||
|
|
* throughput: kbs (kilo bit / sec)
|
||
|
|
|
||
|
|
The infrastructure exposes multiple misc device nodes one per implemented
|
||
|
|
parameter. The set of parameters implement is defined by pm_qos_power_init()
|
||
|
|
and pm_qos_params.h. This is done because having the available parameters
|
||
|
|
being runtime configurable or changeable from a driver was seen as too easy to
|
||
|
|
abuse.
|
||
|
|
|
||
|
|
For each parameter a list of performance requirements is maintained along with
|
||
|
|
an aggregated target value. The aggregated target value is updated with
|
||
|
|
changes to the requirement list or elements of the list. Typically the
|
||
|
|
aggregated target value is simply the max or min of the requirement values held
|
||
|
|
in the parameter list elements.
|
||
|
|
|
||
|
|
From kernel mode the use of this interface is simple:
|
||
|
|
pm_qos_add_requirement(param_id, name, target_value):
|
||
|
|
Will insert a named element in the list for that identified PM_QOS parameter
|
||
|
|
with the target value. Upon change to this list the new target is recomputed
|
||
|
|
and any registered notifiers are called only if the target value is now
|
||
|
|
different.
|
||
|
|
|
||
|
|
pm_qos_update_requirement(param_id, name, new_target_value):
|
||
|
|
Will search the list identified by the param_id for the named list element and
|
||
|
|
then update its target value, calling the notification tree if the aggregated
|
||
|
|
target is changed. with that name is already registered.
|
||
|
|
|
||
|
|
pm_qos_remove_requirement(param_id, name):
|
||
|
|
Will search the identified list for the named element and remove it, after
|
||
|
|
removal it will update the aggregate target and call the notification tree if
|
||
|
|
the target was changed as a result of removing the named requirement.
|
||
|
|
|
||
|
|
|
||
|
|
From user mode:
|
||
|
|
Only processes can register a pm_qos requirement. To provide for automatic
|
||
|
|
cleanup for process the interface requires the process to register its
|
||
|
|
parameter requirements in the following way:
|
||
|
|
|
||
|
|
To register the default pm_qos target for the specific parameter, the process
|
||
|
|
must open one of /dev/[cpu_dma_latency, network_latency, network_throughput]
|
||
|
|
|
||
|
|
As long as the device node is held open that process has a registered
|
||
|
|
requirement on the parameter. The name of the requirement is "process_<PID>"
|
||
|
|
derived from the current->pid from within the open system call.
|
||
|
|
|
||
|
|
To change the requested target value the process needs to write a s32 value to
|
||
|
|
the open device node. This translates to a pm_qos_update_requirement call.
|
||
|
|
|
||
|
|
To remove the user mode request for a target value simply close the device
|
||
|
|
node.
|
||
|
|
|
||
|
|
|
||
|
|
|