20 Jan, 2010

1 commit


31 Dec, 2009

1 commit

  • There are some fixes listed below:
    1. When met a bogus BIOS, the return value of cpu number maybe is
    a negative value so that acpi_pad_pur get an unexpected result.
    2. the return value of function acpi_pad_idle_cpus is useless.
    3. enhance the process of create_power_saving_task/destroy_power_saving_task
    4. Add more error checks when evaluating _PUR object.
    5. one typo fix

    Signed-off-by: Chen Gong
    Acked-by: Shaohua Li
    Signed-off-by: Len Brown

    Chen Gong
     

16 Dec, 2009

1 commit

  • drivers/acpi/acpi_pad.c: In function 'power_saving_thread':
    drivers/acpi/acpi_pad.c:103: warning: 'preferred_cpu' may be used uninitialized in this function

    Cc: Shaohua Li
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Andrew Morton
     

01 Aug, 2009

1 commit

  • ACPI 4.0 created the logical "processor aggregator device" as
    a mechinism for platforms to ask the OS to force otherwise busy
    processors to enter (power saving) idle.

    The intent is to lower power consumption to ride-out
    transient electrical and thermal emergencies,
    rather than powering off the server.

    On platforms that can save more power/performance via P-states,
    the platform will first exhaust P-states before forcing idle.
    However, the relative benefit of P-states vs. idle states
    is platform dependent, and thus this driver need not know
    or care about it.

    This driver does not use the kernel's CPU hot-plug mechanism
    because after the transient emergency is over, the system must
    be returned to its normal state, and hotplug would permanently
    break both cpusets and binding.

    So to force idle, the driver creates a power saving thread.
    The scheduler will migrate the thread to the preferred CPU.
    The thread has max priority and has SCHED_RR policy,
    so it can occupy one CPU. To save power, the thread will
    invoke the deep C-state entry instructions.

    To avoid starvation, the thread will sleep 5% of the time
    time for every second (current RT scheduler has threshold
    to avoid starvation, but if other CPUs are idle,
    the CPU can borrow CPU timer from other,
    which makes the mechanism not work here)

    Vaidyanathan Srinivasan has proposed scheduler enhancements
    to allow injecting idle time into the system. This driver doesn't
    depend on those enhancements, but could cut over to them
    when they are available.

    Peter Z. does not favor upstreaming this driver until
    the those scheduler enhancements are in place. However,
    we favor upstreaming this driver now because it is useful
    now, and can be enhanced over time.

    Signed-off-by: Shaohua Li
    NACKed-by: Peter Zijlstra
    Cc: Vaidyanathan Srinivasan
    Signed-off-by: Len Brown

    Shaohua Li