Commit [333c5a]  Maximize  Restore  History

idle governor: Avoid lock acquisition to read pm_qos before entering idle

Thanks to the reviews and comments by Rafael, James, Mark and Andi.
Here's version 2 of the patch incorporating your comments and also some
update to my previous patch comments.

I noticed that before entering idle state, the menu idle governor will
look up the current pm_qos target value according to the list of qos
requests received. This look up currently needs the acquisition of a
lock to access the list of qos requests to find the qos target value,
slowing down the entrance into idle state due to contention by multiple
cpus to access this list. The contention is severe when there are a lot
of cpus waking and going into idle. For example, for a simple workload
that has 32 pair of processes ping ponging messages to each other, where
64 cpu cores are active in test system, I see the following profile with
37.82% of cpu cycles spent in contention of pm_qos_lock:

- 37.82% swapper [kernel.kallsyms] [k]
- _raw_spin_lock_irqsave
- 95.65% pm_qos_request
- cpu_idle
99.98% start_secondary

A better approach will be to cache the updated pm_qos target value so
reading it does not require lock acquisition as in the patch below.
With this patch the contention for pm_qos_lock is removed and I saw a
2.2X increase in throughput for my message passing workload.

Signed-off-by: Tim Chen <>
Acked-by: Andi Kleen <>
Acked-by: James Bottomley <>
Acked-by: mark gross <>
Signed-off-by: Len Brown <>

Tim Chen Tim Chen 2011-02-11

Len Brown Len Brown 2011-05-29

changed include
changed include/linux
changed include/linux/pm_qos_params.h
changed kernel
changed kernel/pm_qos_params.c
include/linux/pm_qos_params.h Diff Switch to side-by-side view
kernel/pm_qos_params.c Diff Switch to side-by-side view