Commit ed77134b authored by Mark Gross's avatar Mark Gross Committed by Rafael J. Wysocki
Browse files

PM QOS update 



This patch changes the string based list management to a handle base
implementation to help with the hot path use of pm-qos, it also renames
much of the API to use "request" as opposed to "requirement" that was
used in the initial implementation.  I did this because request more
accurately represents what it actually does.

Also, I added a string based ABI for users wanting to use a string
interface.  So if the user writes 0xDDDDDDDD formatted hex it will be
accepted by the interface.  (someone asked me for it and I don't think
it hurts anything.)

This patch updates some documentation input I got from Randy.

Signed-off-by: default avatarmarkgross <mgross@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
parent 0fef8b1e

Documentation/power/pm_qos_interface.txt

+25 −23
Original line number Diff line number Diff line
@@ -18,44 +18,46 @@ 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

For each parameter a list of performance requests 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

changes to the request list or elements of the list.  Typically the

aggregated target value is simply the max or min of the request 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.

handle = pm_qos_add_request(param_class, target_value):

Will insert an element into the list for that identified PM_QOS class 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.

Clients of pm_qos need to save the returned handle.



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.

void pm_qos_update_request(handle, new_target_value):

Will update the list element pointed to by the handle with the new target value

and recompute the new aggregated target, calling the notification tree if the

target is changed.



void pm_qos_remove_request(handle):

Will remove the element.  After removal it will update the aggregate target and

call the notification tree if the target was changed as a result of removing

the request.





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:

Only processes can register a pm_qos request.  To provide for automatic

cleanup of a process, the interface requires the process to register its

parameter requests 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.

request on the parameter.



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 change the requested target value the process needs to write an s32 value to

the open device node.  Alternatively the user mode program could write a hex

string for the value using 10 char long format e.g. "0x12345678".  This

translates to a pm_qos_update_request call.



To remove the user mode request for a target value simply close the device

node.

drivers/acpi/processor_idle.c

+1 −1
Original line number Diff line number Diff line
@@ -698,7 +698,7 @@ static int acpi_processor_power_seq_show(struct seq_file *seq, void *offset) 
		   "max_cstate:              C%d\n"

		   "maximum allowed latency: %d usec\n",

		   pr->power.state ? pr->power.state - pr->power.states : 0,

		   max_cstate, pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY));

		   max_cstate, pm_qos_request(PM_QOS_CPU_DMA_LATENCY));



	seq_puts(seq, "states:\n");

drivers/cpuidle/governors/ladder.c

+1 −1
Original line number Diff line number Diff line
@@ -67,7 +67,7 @@ static int ladder_select_state(struct cpuidle_device *dev) 
	struct ladder_device *ldev = &__get_cpu_var(ladder_devices);

	struct ladder_device_state *last_state;

	int last_residency, last_idx = ldev->last_state_idx;

	int latency_req = pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY);

	int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);



	/* Special case when user has set very strict latency requirement */

	if (unlikely(latency_req == 0)) {

drivers/cpuidle/governors/menu.c

+1 −1
Original line number Diff line number Diff line
@@ -182,7 +182,7 @@ static u64 div_round64(u64 dividend, u32 divisor) 
static int menu_select(struct cpuidle_device *dev)

{

	struct menu_device *data = &__get_cpu_var(menu_devices);

	int latency_req = pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY);

	int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);

	int i;

	int multiplier;

drivers/net/e1000e/netdev.c

+12 −10
Original line number Diff line number Diff line
@@ -2524,11 +2524,11 @@ static void e1000_configure_rx(struct e1000_adapter *adapter) 
			 * excessive C-state transition latencies result in

			 * dropped transactions.

			 */

			pm_qos_update_requirement(PM_QOS_CPU_DMA_LATENCY,

						  adapter->netdev->name, 55);

			pm_qos_update_request(

				adapter->netdev->pm_qos_req, 55);

		} else {

			pm_qos_update_requirement(PM_QOS_CPU_DMA_LATENCY,

						  adapter->netdev->name,

			pm_qos_update_request(

				adapter->netdev->pm_qos_req,

				PM_QOS_DEFAULT_VALUE);

		}

	}
@@ -2824,8 +2824,8 @@ int e1000e_up(struct e1000_adapter *adapter) 


	/* DMA latency requirement to workaround early-receive/jumbo issue */

	if (adapter->flags & FLAG_HAS_ERT)

		pm_qos_add_requirement(PM_QOS_CPU_DMA_LATENCY,

		                       adapter->netdev->name,

		adapter->netdev->pm_qos_req =

			pm_qos_add_request(PM_QOS_CPU_DMA_LATENCY,

				       PM_QOS_DEFAULT_VALUE);



	/* hardware has been reset, we need to reload some things */
@@ -2887,9 +2887,11 @@ void e1000e_down(struct e1000_adapter *adapter) 
	e1000_clean_tx_ring(adapter);

	e1000_clean_rx_ring(adapter);



	if (adapter->flags & FLAG_HAS_ERT)

		pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,

		                          adapter->netdev->name);

	if (adapter->flags & FLAG_HAS_ERT) {

		pm_qos_remove_request(

			      adapter->netdev->pm_qos_req);

		adapter->netdev->pm_qos_req = NULL;

	}



	/*

	 * TODO: for power management, we could drop the link and

CRA Git | Maintained and supported by SUSTech CRA and CCSE