Hi All,
This patch takes advantage of the infrastructure introduced in the last
patch, and allows the processor idle algorithm to proactively choose a
c-state based on the time the next timer interrupt is expected to occur.
It preserves the residency metric, so the algorithm should, in theory,
remain effective against bursts of activity from other interrupt
sources.
This patch is mostly intended to be illustrative. There may be some
"#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
implementing this more cleanly.
Cheers,
Adam
Patch is against 2.6.18-rc4.
Signed-off-by: Adam Belay <[email protected]>
---
drivers/acpi/processor_idle.c | 17 +++++++++++++++++
include/acpi/processor.h | 2 ++
kernel/timer.c | 7 +++++++
3 files changed, 26 insertions(+)
--- a/drivers/acpi/processor_idle.c 2006-08-28 17:14:54.000000000 -0400
+++ b/drivers/acpi/processor_idle.c 2006-08-28 17:29:21.000000000 -0400
@@ -64,6 +64,7 @@
* Currently, we aim for the entry/exit latency to be 20% of measured residency.
*/
#define RESIDENCY_TO_LATENCY_RATIO 5
+#define TIMER_TICKS (PM_TIMER_FREQUENCY / HZ)
/* --------------------------------------------------------------------------
Power Management
@@ -271,6 +272,22 @@
int count = min(pr->power.count, (int) max_cstate);
cx = &pr->power.states[state_idx];
+ /*
+ * We are proactive with timer interrupts. After a timer
+ * interrupt has occurred the previous sleep_ticks value is
+ * restored.
+ */
+ if (pr->power.pretimer_last_ticks) {
+ sleep_ticks = pr->power.pretimer_last_ticks;
+ pr->power.pretimer_last_ticks = 0;
+ }
+ t1 = inl(acpi_fadt.xpm_tmr_blk.address);
+ i = TIMER_TICKS - t1 + pr->power.timer_tick;
+ if (i < sleep_ticks) {
+ pr->power.pretimer_last_ticks = sleep_ticks;
+ sleep_ticks = i;
+ }
+
if (cx->target_ticks < sleep_ticks) { /* promotion */
for (i = state_idx + 1; i <= count; i++) {
cx = &pr->power.states[i];
--- a/kernel/timer.c 2006-08-03 13:39:22.000000000 -0400
+++ b/kernel/timer.c 2006-08-28 17:16:36.000000000 -0400
@@ -41,6 +41,9 @@
#include <asm/timex.h>
#include <asm/io.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/processor.h>
+
#ifdef CONFIG_TIME_INTERPOLATION
static void time_interpolator_update(long delta_nsec);
#else
@@ -1175,6 +1178,10 @@
{
struct task_struct *p = current;
int cpu = smp_processor_id();
+ struct acpi_processor *pr = processors[cpu];
+
+ if (pr)
+ pr->power.timer_tick = inl(acpi_fadt.xpm_tmr_blk.address);
/* Note: this timer irq context must be accounted for as well. */
if (user_tick)
--- a/include/acpi/processor.h 2006-08-28 17:14:54.000000000 -0400
+++ b/include/acpi/processor.h 2006-08-28 17:20:25.000000000 -0400
@@ -60,6 +60,8 @@
u32 bm_activity;
u32 bm_veto_state;
u32 last_ticks;
+ u32 timer_tick;
+ u32 pretimer_last_ticks;
int count;
struct acpi_processor_cx states[ACPI_PROCESSOR_MAX_POWER];
};
Hi!
> This patch takes advantage of the infrastructure introduced in the last
> patch, and allows the processor idle algorithm to proactively choose a
> c-state based on the time the next timer interrupt is expected to occur.
> It preserves the residency metric, so the algorithm should, in theory,
> remain effective against bursts of activity from other interrupt
> sources.
>
> This patch is mostly intended to be illustrative. There may be some
> "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> implementing this more cleanly.
>
> Cheers,
> Adam
> --- a/kernel/timer.c 2006-08-03 13:39:22.000000000 -0400
> +++ b/kernel/timer.c 2006-08-28 17:16:36.000000000 -0400
> @@ -41,6 +41,9 @@
> #include <asm/timex.h>
> #include <asm/io.h>
>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/processor.h>
> +
I sense a problem here, like broken compilation for all non-x86
platforms.
> @@ -1175,6 +1178,10 @@
> {
> struct task_struct *p = current;
> int cpu = smp_processor_id();
> + struct acpi_processor *pr = processors[cpu];
> +
> + if (pr)
> + pr->power.timer_tick = inl(acpi_fadt.xpm_tmr_blk.address);
>
This probably needs to be encapsulated, somehow.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > > This patch takes advantage of the infrastructure introduced in the last
> > > patch, and allows the processor idle algorithm to proactively choose a
> > > c-state based on the time the next timer interrupt is expected to occur.
> > > It preserves the residency metric, so the algorithm should, in theory,
> > > remain effective against bursts of activity from other interrupt
> > > sources.
> > >
> > > This patch is mostly intended to be illustrative. There may be some
> > > "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> > > implementing this more cleanly.
>
> Okay, just to get you some feedback:
>
> It seems to change things a _lot_. Power consumption with usb modules
> loaded went from 14315mW to 13800mW -- that is huge
> deal. Unfortunately something strange is going on: with stock kernel,
> power consumption is mostly constant. With your patch, it varies a
> lot, at 2 second timescale.
>
> Power consumption with usb unloaded (only way to get reasonable power
> on x60) went from stable 10450mW to something rapidly changing, and
> probably even worse than original:
I also noticed that with your patch, bus master activity tends to be constant?!
root@amd:/data/l/tp/tp_smapi-0.22# cat /proc/acpi/processor/CPU0/power
active state: C3
max_cstate: C8
bus master activity: 37244
states:
C1: type[C1] latency[000] usage[00000067]
duration[00000000000000000067]
C2: type[C2] latency[001] usage[00042173]
duration[00000000000454647687]
*C3: type[C3] latency[057] usage[00290242]
duration[00000000003402855375]
root@amd:/data/l/tp/tp_smapi-0.22# cat /proc/acpi/processor/CPU0/power
active state: C3
max_cstate: C8
bus master activity: 37244
states:
C1: type[C1] latency[000] usage[00000067]
duration[00000000000000000067]
C2: type[C2] latency[001] usage[00042274]
duration[00000000000454688808]
*C3: type[C3] latency[057] usage[00305466]
duration[00000000003595077816]
root@amd:/data/l/tp/tp_smapi-0.22#
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > This patch takes advantage of the infrastructure introduced in the last
> > patch, and allows the processor idle algorithm to proactively choose a
> > c-state based on the time the next timer interrupt is expected to occur.
> > It preserves the residency metric, so the algorithm should, in theory,
> > remain effective against bursts of activity from other interrupt
> > sources.
> >
> > This patch is mostly intended to be illustrative. There may be some
> > "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> > implementing this more cleanly.
Okay, just to get you some feedback:
It seems to change things a _lot_. Power consumption with usb modules
loaded went from 14315mW to 13800mW -- that is huge
deal. Unfortunately something strange is going on: with stock kernel,
power consumption is mostly constant. With your patch, it varies a
lot, at 2 second timescale.
Power consumption with usb unloaded (only way to get reasonable power
on x60) went from stable 10450mW to something rapidly changing, and
probably even worse than original:
current average
-11200 mW avg -11274 mW
-10505 mW avg -11251 mW
-11701 mW avg -11238 mW
-11975 mW avg -11348 mW
-10432 mW avg -11313 mW
-11944 mW avg -11422 mW
-10683 mW avg -11504 mW
-10682 mW avg -11457 mW
-10402 mW avg -11432 mW
-11913 mW avg -11317 mW
-12004 mW avg -11541 mW
-12004 mW avg -11661 mW
-11945 mW avg -11781 mW
-11943 mW avg -11824 mW
-12577 mW avg -11891 mW
-12004 mW avg -11930 mW
-12019 mW avg -11944 mW
-11972 mW avg -12002 mW
-12004 mW avg -11990 mW
-11913 mW avg -12032 mW
-11083 mW avg -11903 mW
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 2006-09-05 at 11:03 +0200, Pavel Machek wrote:
> Hi!
>
> > > > This patch takes advantage of the infrastructure introduced in the last
> > > > patch, and allows the processor idle algorithm to proactively choose a
> > > > c-state based on the time the next timer interrupt is expected to occur.
> > > > It preserves the residency metric, so the algorithm should, in theory,
> > > > remain effective against bursts of activity from other interrupt
> > > > sources.
> > > >
> > > > This patch is mostly intended to be illustrative. There may be some
> > > > "#ifdef CONFIG_ACPI" issues, and I would appreciate any advice on
> > > > implementing this more cleanly.
> >
> > Okay, just to get you some feedback:
> >
> > It seems to change things a _lot_. Power consumption with usb modules
> > loaded went from 14315mW to 13800mW -- that is huge
> > deal. Unfortunately something strange is going on: with stock kernel,
> > power consumption is mostly constant. With your patch, it varies a
> > lot, at 2 second timescale.
> >
> > Power consumption with usb unloaded (only way to get reasonable power
> > on x60) went from stable 10450mW to something rapidly changing, and
> > probably even worse than original:
>
> I also noticed that with your patch, bus master activity tends to be constant?!
Is this the case even when userspace touches the disk? On my hardware I
see a constant flow of short BM activity bursts.
Thanks,
Adam
Hi!
> > > Okay, just to get you some feedback:
> > >
> > > It seems to change things a _lot_. Power consumption with usb modules
> > > loaded went from 14315mW to 13800mW -- that is huge
> > > deal. Unfortunately something strange is going on: with stock kernel,
> > > power consumption is mostly constant. With your patch, it varies a
> > > lot, at 2 second timescale.
> > >
> > > Power consumption with usb unloaded (only way to get reasonable power
> > > on x60) went from stable 10450mW to something rapidly changing, and
> > > probably even worse than original:
> >
> > I also noticed that with your patch, bus master activity tends to be constant?!
>
> Is this the case even when userspace touches the disk? On my hardware I
> see a constant flow of short BM activity bursts.
Disk was active (like once 5 seconds some small access)...
Pavel
--
Thanks, Sharp!
I ran bltk this patch vs 2.6.18.1 on a Dell i6400 Core Duo laptop.
Initial result (1 measurement of each kernel) is that
battery life is unchanged, but response time improves with the new patch.
Summary files attached.
thanks,
-Len