summaryrefslogtreecommitdiff
path: root/drivers/acpi/processor_idle.c
diff options
context:
space:
mode:
authorLen Brown <len.brown@intel.com>2007-12-14 00:24:15 -0500
committerLen Brown <len.brown@intel.com>2007-12-14 00:24:15 -0500
commit25de5718356e264820625600a9edca1df5ff26f8 (patch)
tree8ff2520cfa979efcc84c69a7bd3b74a0a8370cfc /drivers/acpi/processor_idle.c
parent4963f62045b64f93c45fbcb6f8f0baf1e3e7a127 (diff)
downloadlwn-25de5718356e264820625600a9edca1df5ff26f8.tar.gz
lwn-25de5718356e264820625600a9edca1df5ff26f8.zip
cpuidle: default processor.latency_factor=2
More aggressively request deep C-states. Note that the job of the OS is to minimize latency impact to expected break events such as interrupts. It is not the job of the OS to try to calculate if the C-state will reach energy break-even. The platform doesn't give the OS enough information for it to make that calculation. Thus, it is up to the platform to decide if it is worth it to go as deep as the OS requested it to, or if it should internally demote to a more shallow C-state. But the converse is not true. The platform can not promote into a deeper C-state than the OS requested else it may violate latency constraints. So it is important that the OS be aggressive in giving the platform permission to enter deep C-states. Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'drivers/acpi/processor_idle.c')
-rw-r--r--drivers/acpi/processor_idle.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 26ade1f3f5cd..bc99b7b9094f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -95,7 +95,7 @@ module_param(bm_history, uint, 0644);
static int acpi_processor_set_power_policy(struct acpi_processor *pr);
#else /* CONFIG_CPU_IDLE */
-static unsigned int latency_factor __read_mostly = 6;
+static unsigned int latency_factor __read_mostly = 2;
module_param(latency_factor, uint, 0644);
#endif