Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=25de5718356e264820625600a9edca1df5ff26f8
Commit:     25de5718356e264820625600a9edca1df5ff26f8
Parent:     4963f62045b64f93c45fbcb6f8f0baf1e3e7a127
Author:     Len Brown <[EMAIL PROTECTED]>
AuthorDate: Fri Dec 14 00:24:15 2007 -0500
Committer:  Len Brown <[EMAIL PROTECTED]>
CommitDate: Fri Dec 14 00:24:15 2007 -0500

    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 <[EMAIL PROTECTED]>
---
 drivers/acpi/processor_idle.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 26ade1f..bc99b7b 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
 
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to